Original from  Darin McBride  to Peter Fitzsimmons on 08-20-1996
Original Subject: Semaphore

                         ---------------------------------------

  DAB>   Well, I have used DosEnterCritSec when I had to 
  DAB> call a time-critical
  DAB> communications routine in order to prevent timeouts 
  DAB> (Communicating with weird PLC's).
  DAB>   I needed to be sure that when I went into that 
  DAB> routine, everything else
  DAB> stopped until it was completed.  It WAS designed to 
  DAB> be as quick as possible.
  DAB>   I don't think I'm being lazy... I just wanted to 
  DAB> point out that I think
  DAB> that there are legitimate uses for DosEnterCritSec.
 
 
  PF> I don't think that is a legitimate use,  because it is 
  PF> working around a design flaw in the program (you have 
  PF> free-running polling loops in the other threads).
 
DM> I might want to point out that this particular PLC and the 
DM> method of communication requires approximately 2ms accuracy 
DM> (on a serial port, for cryin' out loud!), otherwise the 
DM> network may be compromised.  You pass a token around at 
DM> 9600 baud, but have to release the token within about 2ms 
DM> if you aren't going to do anything with it.

 In that case, EnterCritSec is *NOT* what you want to do. This API 
only affects the other threads IN THE SAME PROCESS. If you are dealing
with time critical apps/threads, then you should use priority boost
adjustment or an interrupt driven device driver (and yes, you can get 
timer notifications in your DD).. 


DM> It's really a pathetic protocol, IMO.  We were about to 
DM> support it, but decided that it wasn't worth the problems.  
DM> (Mind you, we're under NT at work)

 Hmm.. Irrelevent to the discussion I would say .. 



   Denis       

 Certified OS/2 Engineer, Certified OS/2 Instructor, Certifiable....
 All opinions are my very own, IBM has no claim upon them
 
.
--- Maximus/2 3.01