-=> Quoting Jerry Coffin to Darin Mcbride
 GD> You're over my head here.  If I am using the modem under NT, say
 GD> in a bbs program, would I get down to the stack level?
 
 DM> Nope - you just use DosRead (OS/2) or whatever under NT, and be happy
 DM> that the device driver is handling that for you.  You don't worry
 DM> about contention - the device driver does.
 JC> It's harder to find under NT, since it's cleverly hidden under the
 JC> name ReadFile.
Hey, gimme a break.  It's been almost a year since I've done any Win32
programming.  I knew it was the same layout, just different API names.
 DM> Well, no one said multithreaded programming was easy.  Not anyone *I*
 DM> know has said that anyway.  :-)
 JC> Actually, with proper use, threads can make some programs tremendously
 JC> easier to write.  For instance, in a simulation you typically have
 JC> separate things (typically objects) that each act more or less
 JC> independently from other things.  Without threads, you typically make
 JC> a big table of things, and step through the table, making each thing
 JC> carry out whatever actions it's supposed to do.
Yeah - the table, with inheritance (something on topic here, anyway) isn't
that bad, really.  Just another message loop ala Win 3.1 flavour.  :-)
However, you're right - there are things that are much more difficult to do
in single-threaded programs.  The difficult part of multithreading is keeping
your head around everything and ensuring as little contention as possible.
 JC> With multiple threads, you simply spawn off a thread for each object
 JC> you care about, and let the OS handle the part with stepping through
 JC> each one and making them run in turn.
True - code reuse at its best.  :-)
 JC> However, multiple threads makes volatile even MORE important rather
 JC> than less so.  Even though you use mutexes or critical sections to
 JC> control access to shared objects, you still have to inform the compiler
 JC> that these objects may change without its knowledge, so it has to
 JC> actually read/write the value from/to memory rather than caching it in
 JC> a register.
Thanks for reminding me.  [goes off and puts volatile in front of a couple of
mutex'ed objects in my class...]
 DM> So... I take it you don't want to write device drivers?  ;-)
 JC> I don't particularly.  I do it fairly regularly, but out of
 JC> necessity... Later,
I'd like to learn, actually.  Not likely any time soon, though.
... I am Pentium of Borg.  Division is futile.  You will be approximated.
--- FastEcho 1.46
---------------