[Tinyos-help] Re: [Tinyos-devel] DAC and MSP430RefVoltGenerator in T2

[Philip Levis]

On Feb 15, 2008, at 10:48 AM, Andreas Koepke wrote:

> Philip Levis:
>> On Feb 15, 2008, at 1:45 AM, Jan Hauer wrote:
>>>> If you don't have separate arbiters for the ADC and the DAC how can
>>>>  you ever allow them to perform operations in parallel?  And  
>>>> this sort
>>>>  of cascading through multiple levels of arbitration happens all  
>>>> the
>>>>  time.  Think about how the flash drivers on telos work.  There is
>>>>  arbitration to the flash operations themselves, sitting on top of
>>>>  arbitration to the msp430 usart underneath.
>>>
>>> As long as two resources were not "double used" this practically  
>>> never
>>> was an issue, but now it becomes more probable:
>>>
>>> AdcClient1 successfully requests RefVolt.
>>> Then AdcClient2 successfully requests ADC.
>>> Then AdcClient1 blocks on request to ADC.
>>> Then AdcClient2 blocks on request to RefVolt.
>>> Deadlock.
>>>
>>> Pushing the solution to upper layers is dangerous - I'm saying we
>>> should avoid this situation as much as we can in the first place.
>>> Maybe we can think of other solutions, e.g. wrappers that perform
>>> multiple request operations for you (in a non-greedy way) on top of
>>> multiple arbiters.
>> Sure, badly written locking code can cause deadlock. Is there a  
>> case when a client wants the ADC but *not* the RefVolt? The  
>> typical solution to this is to layer them. There are many examples  
>> where an abstraction needs multiple resources. The arbiters paper  
>> in SOSP goes into how you do this, with the Light/Temp sensor  
>> board example. On the micasb, both sensors requires the ADC and  
>> share a pin; so you acquire the pin before putting a request to  
>> the ADC (Figure 13).
>
> Yes -- you can also use Vcc as reference for the ADC. This is how I  
> do CCA on the eyesIFX, switching around with the RefVolt would take  
> too much time, and precision is not needed.

OK, so you layer the components such that there is a lock order. You  
shouldn't be pushing the lock order to upper layers. In the best  
case, abstract through interfaces so you have a single piece of code  
that has a single order. In the worst case, make sure the small  
number of implementations all do it correctly.

Phil