On (24 Aug 97) Darin Mcbride wrote to Jerry Coffin...
 JC> ...or maybe not so simple -- quite a few versions of STL aren't
 JC> safe for multithreaded use.  I've been working on making the
 JC> version that came with VC++ 4.2 completely thread-safe, and though
 JC> I'm not done yet, it's the only one I've personally seen that was
 JC> even close.
 DM> Hmmmm... true.  What do you do to make it "thread-safe"?  Any
 DM> semaphoring, or just the volatile, letting the user do the semaphores?
Well, I'm actually using critical sections instead of semaphores, but
the idea's the same, just critical sections are much lower overhead in
Win32.  In Win32, semapores and mutexes are kernel objects manipulated
only by kernel code, where critical sections are process-specific and
are manipulated entirely in user-mode.
 DM> Now that you mention it, someone was advertising about having a
 DM> thread-safe version of STL available... let's see if I can find the
 DM> message... SGI says it's on: http://www.sgi.com/Technology/STL.
Actually, I've got a copy of that that was supposedly adapted to VC++ on
Win32, but I haven't been able to get it to work for me.
 DM> Device driver, of course.  :-)  This'd be a bigger mess if I were
 DM> forced to do this under DOS.  Mind you, between the two of us, I'd
 DM> say we'd have a hard time giving half a darn about DOS - and that's
 DM> assuming you give a full darn about DOS!  ;-)
Me care about DOS?  Yes, I actually do care about DOS deeply, in much
the way I care deeply about mid-east terrorism.  I wish they'd both just
go away and let the rest of us live in peace. 
 JC> Three things: what version of STL are you using, what compiler
 JC> are you using, and what are the errors you get?
 DM> GCC.  That should about explain it.  ;-)
Maybe...
 DM> The errors are asking me to find a type::func(...) volatile function
 DM> which, obviously, doesn't exist when my variable of type "type" is
 DM> volatile. i.e.:
 DM> volatile queue > IOQueue;
 DM> IOQueue.push('c'); // no queue >::push(char) volatile!
 DM> So, at the least, I expect that volatile functions are required...
Sounds about right.
 JC> That might depend.  Assuming that you're working with a device
 JC> driver for the serial port rather than driving the hardware
 JC> directly yourself the data may be sitting in the device driver's
 JC> queue for a while.
 DM> Yeah, that was it - I found that one a few hours later.  Had to drop
 DM> my read to 1 character at a time unless I know there is more waiting.
Hmmm...can't you set a time-out on reading from the serial ports?  I
never did much with serial ports under OS/2, but I _thought_ I
remembered being able to set the timeout with DosDevIOCtl or somesuch.
 DM> As I said, I use the device driver.  I know SIO has a 4k buffer for
 DM> each com port - although I'm unsure if it dynamically "splits" to
 DM> whatever is needed for each buffer, or if that's 4k for each read
 DM> and write queue on each port.
Offhand, I'm not at all sure, though if memory serves, you can also
adjust the size in config.sys. (Or has OS/2 renamed that - I think it
was config.sys the last time I looked though...)
 JC> Writing is generally less difficult than reading, unless you work
 JC> with a file transfer protocol that has a timeout.  Otherwise the
 JC> worst that can generally happen is that you reduce the throughput
 JC> of the port.
 DM> This would generally be a bad thing, too.  ;-)
Yes and no.  If you miss reading even a single character while doing
something like a binary file transfer without an error-checking
protocol, you have a real problem.  Even missing one character in a
million by a millisecond or so means your file transfers are always
highly suspect.
By contrast, if you miss writing one character in a million by a
millisecond or so, the drop in throughput is far too small for most
people to care about.
 DM> Which is why I wanted the "infinite" read buffers.
The proble here is that in creating an "infinite" read buffer, you're
likely to end up doing dynamic allocation.  Unfortunately, the
allocation itself is likely to take long enough that you could well end
up losing characters while you do it unless you use flow control to stop
the input while you do the allocation.
 DM> I've got my own queue class that is thread-safe (I think), complete
 DM> with semaphores.  (Well, semaphore.  One per object.)  It seems to
 DM> work so far.
That's always a good sign, but not always an assurance of correctness
when you're doing multithreading.  I had some multithreaded code that
worked beautifully for years, but crashed almost _instantly_ the first
time I had it on a multiprocessor machine.
As always, testing can assure you that bugs are present, but can never
assure you that they're not...
 DM> The one thing I dislike somewhat is that I'm going to have to make
 DM> my events public... so that the caller can use multiple-wait (mux)
 DM> calls to wait on read, write, and, say, a keyboard thread, or any
 DM> other thread.  I could "demand" (via interface restrictions) that
 DM> the user of this class was its own thread, but threads have costs,
 DM> too... ah well, the joys of design.  :-)
Yup, it's definitely a pain.  Another possibility I've considered is
a class for doing the waiting on various events, and make it a friend of
the class(es) that use events internally, as well as having conversions
from the native OS event data structures.  This was you still restrict
the visibility of the event(s) in your class to one specific place
rather than the whole world.
On the down side, it still implies tight coupling between the event
class and the other classes that use events internally.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------