-=> Quoting Gerry Danen to Darin Mcbride
 GD> I've never used volatile on any direct screen I/O.  Perhaps that's
 GD> because under single-tasking DOS that's not a problem.  In what way
 GD> would I see problems under multi-tasking OS like WinNT or OS/2?
 
 DM> Something tells me you just wanted the answer to the other question,
 DM> but had to keep it on topic.  That's ok - I'm not the moderator, and
 DM> thus the moderator isn't so anal that he'd care.  :-)  [There's an
 DM> implication in there somewhere... ]
 GD> I hope Tom isn't reading this... 
(I said something about _me_ not being the moderator... Tom doesn't read the
echoes he moderates!)
 DM> Anyway, you would use volatile under DOS for global variables that are
 DM> modified by interrupts, or anything else modified by interrupts for
 DM> that matter.
 GD> Or another process?
Well, that's often difficult in DOS.  Even when you can - NT or OS/2 - each
DOS session should be protected from each other.
(Hey, maybe THAT's where they get this "protected-mode" buzzword from... )
 DM> For example, if you had an interrupt that changed a global stack to
 DM> add each new character that came in from a modem, anything dealing with
 DM> the stack would have to be considered volatile (in OS/2 or NT, you
 DM> would use semaphores to guarantee the variable didn't change between
 DM> accesses).  Another one would be, say a pointer to the incoming byte of
 DM> a serial port - this would be volatile as well.
 GD> You're over my head here.  If I am using the modem under NT, say in a
 GD> bbs program, would I get down to the stack level?
Nope - you just use DosRead (OS/2) or whatever under NT, and be happy that
the device driver is handling that for you.  You don't worry about contention
- the device driver does.
 DM> OS/2 and WinNT have semaphores that render volatile mostly useless.
 DM> Only your own process threads can modify your variables, and all these
 DM> variables can be protected by semaphores.  If they aren't so protected,
 DM> you run into race conditions that can make the system blow up.  ;-)
 GD> Wonderful! :(
Well, no one said multithreaded programming was easy.  Not anyone *I* know
has said that anyway.  :-)
 DM> Same for DOS, but you don't have as much power over it, so you use the
 DM> volatile.
 
 DM> (The screen isn't going to change, so having a volatile pointer to it
 DM> is useless... unless you have an interrupt handler also modifying it.)
 GD> What about concurrent DOS windows?...
Are you asking about protected-mode systems?  OS/2 & NT virtualize the screen
to prevent "bleeding" (a common thing back from DESQview days).  If you think
you're pointing at the video, you aren't.  The CPU, in the current context,
has been told that B000:0000, or whatever, is actually over somewhere else. 
The DOS session never knows.  ;-)  The OS is responsible for ensuring that
two DOS sessions don't both point B000:0000 to the same place.  Of course,
P-mode systems do the same protection for ALL DOS memory (the entire 640K
plus UMB, EMS, XMS, etc.), not just the video.  The fun part comes when the
DOS session tries to play with ports owned by real (i.e., not real-mode)
device drivers.  :-)  (Don't worry - the protection is still available then,
too.)
So... I take it you don't want to write device drivers?  ;-)
... Don't hit me, Mr. Moderator... I'll go back on topic... I swear!
--- FastEcho 1.46
---------------