On (18 Aug 97) Darin Mcbride wrote to Jerry Coffin...
 DM> I'm trying, mostly for the sake of learning, to write a simple
 DM> multi-threaded comm class.  Most of it seems to work, so far, except
 DM> the queues.  I'd like to have a write queue and read queue.  That
 DM> seems simple - there's a deque in the STL.
...or maybe not so simple -- quite a few versions of STL aren't safe for
multithreaded use.  I've been working on making the version that came
with VC++ 4.2 completely thread-safe, and though I'm not done yet, it's
the only one I've personally seen that was even close.
Is your class driving the hardware directly, or does it work through a
device driver? (E.g. under OS/2)
 DM> Except that it doesn't really want to work if I make it volatile.
 DM> If it is volatile, the compiler complains.
Three things: what version of STL are you using, what compiler are you
using, and what are the errors you get?
 DM> If it isn't volatile, it becomes really funny - I write to the
 DM> serial port fine, but reading doesn't always seem to work... if I
 DM> don't give it a long enough delay, the "AT" coming back from the
 DM> modem (which I see in a line monitor) only is discovered if I give
 DM> it a long enough timeout.  I'm sure volatile would help here - if I
 DM> could figure out what I was doing with it.  :-)
That might depend.  Assuming that you're working with a device driver
for the serial port rather than driving the hardware directly yourself
the data may be sitting in the device driver's queue for a while.  If
you're driving the hardware directly yourself, it's less clear what's
likely to be happening -- have you done any debugging to figure out how
long it's taking for your ISR to see the incoming data after the line
monitor sees it?
 DM> Leaving it non-volatile and then removing the thread/queue for reading
 DM> may work.
If you don't have _some_ queueing (either in the device driver, or your
driver, if you're driving the hardware directly) you're almost certain
to lose characters if you don't have a queue on the input.
 DM> However, I'm suspicious that the write queue may not work
 DM> in stress situations (i.e., trying to send a file).
Writing is generally less difficult than reading, unless you work with a
file transfer protocol that has a timeout.  Otherwise the worst that can
generally happen is that you reduce the throughput of the port.  Reading
is different: once a character comes in the port, you need to read it
before the next character arrives, or it'll be destroyed.  If you're
working with a UART that has FIFOs of its own (e.g. 16550), you get a
little reprieve because you don't have to handle every character
immediately.  However, the same general rule holds true: if you don't
read characters quickly enough, you'll end up completely losing
characters.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------