DM> I haven't done much multi-threading (read: practically none) and was
 DM> wondering if anyone would be willing to help me with the design of a
 DM> simple multithreaded object.

 HR> Is your program a PM application?

 HR> No: You my do all your work on one thread.
 HR>     If you have to do some differnt actions at same time you can use
 HR>     one or more threads too.

Yes, I have other work to do, and no, it's a console app.  However, I found
the following (which Daniel Lynes may recognise ) in another
library implementation:

There is a problem in the OS/2 DosRead call in that it will not return
from an attempt to read from a zero length file. So, if the program
attempts to read from the Rcv queue when it is empty, the function
will not return until a character is placed in the Rcv buffer, which
can cause serious time delay problems (or a permanent hang) if the
read code is not implemented in its own thread. To work around this
problem, I have added a new variable SafeToRead in the Rcv functions.
Now, after every read, the function will check if there is any further
data in the queue. If there is no data, but the timeout has not yet
been reached, then the function will wait and either restore read
ability if data is received or wait for the timeout. This means now that
the function will not return until its timeout is reached if the
buffer has not yet been filled.

This implies a wait loop - which is BAD for the CPU.  I want to be able to
block the background thread on DosRead and the foreground thread on a timed
event semaphore (or some other semaphore perhaps - probably a mux since
I'll eventually also want to detect the keyboard in its thread the same
way, so I'll be unblocked whenever a character appears either at the
console or at the serial port).

Also, I know that things like the PMLM that comes with SIO uses two threads
(I use PSPM from DevCon to check this), which is also a console app.

 HR> Yes: You *must* use an other thread for your file I/O 
 HR> because the PM messages must handled alway in 1/10s.

Technically, it is _encouraged_ that the messages be handled that
quickly... :=)  But, yeah, I recall that much.

 HR>      You my syncronize your I/O thread with semaphores of any kind. 
 HR>  But you should block your PM thred ONLY by Mutex semaphore
 HR>  to block simoultanous access to same memory locations or
 HR>  other resources. DON'T block the PM thread by Event semaphores!

Ok, I would think that any time the PM thread had to access something that
may be locked by a semaphore, it should throw it to another thread and
return immediately, otherwise the background thread(s) may lock that PM
thread for more than 0.1s...

Excuse the questions of this PM & multi-threading newbie... I know my
C/C++, but I'm still getting my head around the multi-parts.  :-)

Thanks for your help.


--- Maximus/2 3.01