Hello Mike

 MB> Your design using the mutex semaphore is clearly the right one.  A
 MB> mutex semaphore should be considered to be a component of the
 MB> resource being protected, in this case the buffer, and the code
 MB> should treat it as a token that gives permission to access the
 MB> resource.  You may also want to use an event semaphore so that the
 MB> thread which inserts data can tell the thread which extracts data
 MB> that there is work to be done.

Thanks for your reply.

Since writing the first message, I've progressed to running my test program
twice and sharing the mutex semaphore. And used an event semaphore to exit
the infinite while loops so they are not waiting on the mutex semaphore, so
I could shut down one of the processes without it still owning the mutex
semaphore.

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

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

Alan

--- FleetStreet 1.14 NR