Alan Clifford wrote in a message to Mike Bilow:

 AC> Your message was very encouraging - I'd already got as far
 AC> as thinking that I didn't need to test if the buffer had
 AC> stuff in it, by using an event semaphore.  I also thought
 AC> that perhaps I didn't need to empty the buffer after every
 AC> character received - post the semaphore after 'n' characters
 AC> or allow it to time out in the extracting thread to ensure
 AC> that less than 'n' characters didn't get stuck in the
 AC> buffer.  Although I'm not sure that this would give me any
 AC> advantage.

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

 AC> I am still a rather worried about what happened with my
 AC> little test program, with one thread in one process
 AC> seemingly not releasing time to the other thread and the
 AC> other processses.  Why did the operating system allow this? 
 AC> Presumably, I should give the thread reading from the com.
 AC> port a high priority to ensure that it would not be denied
 AC> time by other processes?  Am I right in thinking that when
 AC> the thread stalls when it is waiting for a character from
 AC> the com. port it will use very little processor time?

A thread will continue to run until its timeslice is exhausted unless it
does something that yields its timeslice either explicitly (DosSleep) or
implicitly (file I/O or a semaphore request).  Requesting a semaphore which
is not immediately available does an implicit yield, but requesting a
semaphore which is immediately available does not do an implicit yield.
 
-- Mike


---