Following up a message from Mike Bilow to Alan Clifford:

 MB> You definitely need to protect the buffer with a mutex
 MB> semaphore, and the overhead of doing so is very small.  You
 MB> can choose to post the event semaphore however often you
 MB> like: after each byte, after each 10 bytes, or after each
 MB> line, as long as you do not overrun the buffer.

As I read my own words again, I realize that I forgot to mention an
additional concern.  If you do not post the event semaphore after every
byte, you must set up a handler for the special case where you get an
otherwise unhandled residue in the buffer.  For example, if you trigger the
event semaphore every 10 bytes, and you physically receive 5 bytes, then
those 5 bytes will sit in the buffer forever unless you either receive 5
more bytes or do something special to get them out of there.

This may sound like a really obvious observation, but it is a common
mistake and often the effort of programming the residue handler is large
enough to quash the idea of posting the event semaphore less often than
every byte. Especially if you have real-time response contraints, the
residue handler can become quite complicated.

One common approach is to use a timer to post the event semaphore.  Then,
when a byte is inserted into the buffer and the timer is not already
running, the timer is started for a one-shot run.  If you make the timer
interval long enough to allow many bytes to enter the buffer when the data
is coming in at full speed, this can improve efficiency by a lot. 
Similarly, the program logic is identical in the case of residue handling,
since the timer is already running regardless of how many more bytes are
received.  One hidden danger to watch here is that you must not allow
enough bytes to accumulate in the buffer that taking them out leaves the
buffer locked so long on the mutex semaphore that the insertion routine
will have to discard a byte.
 
-- Mike


---