[Tinyos Core WG] Small gotcha in UartStream interface

[Jonathan Hui]

Sure, fair enough. I guess it's just protecting the programmer from
programmer error. In either case, it needs to be clearly documented so
people that do want receiveInterrupts renabled must call it within the
receiveDone handler so no bytes are lost.

-- 
Jonathan W. Hui
jwhui at cs.berkeley.edu
http://www.cs.berkeley.edu/~jwhui/

On 10/20/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Oct 20, 2006, at 8:23 PM, Jonathan Hui wrote:
>
> > No race condition here. If a new byte arrives, it's handled when the
> > interrupt handler executes again (of course, it does assume the
> > handler is atomic). One idea is that it "suspends" the byte-by-byte
> > receive, where all it's doing is putting each byte in the receive
> > buffer rather than passing it up. Implicitly calling
> > disableReceiveInterrupt() doesn't really do anything. The hardware
> > still needs to be configured to have receive interrupts enabled,
> > otherwise UartStream.receive() would not work. We could disable it
> > logically, meaning that once receiveDone() returns, you have to
> > explicitly enable interrupts.
>
> What I mean is this:
>
> -> call UartStream.enableReceiveInterrupt();
> -> call UartStream.receive(.....)
> <- event UartStream.receiveDone(....)
> take a while to call receive again
> <- event UartStream.receivedByte()
>
> The race condition is whether you can call receive again quickly
> enough or whether receivedByte occurs. If receive() implicitly
> disables the receive interrupt, then  it's fine. Otherwise, you have
> a race, similar to the original UNIX signal() race (mmm, the mess of
> POSIX). Unless you also signal receivedByte on each byte of the
> receive()?
>
> Phil
>