Original from  Russell Coker  to Denis Tonn on 07-21-1996
Original Subject: Semaphore

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

 DT> EnterCritSec is OK if your app does not have many threads (2-3 max). 
 DT>If you have more than that, then you should use semaphores (local). 
 DT>Critcal sections will stop ALL other threads in your process from 
 DT>running, when most times all you need is to protect a single resource. 
 
RC>    It really depends on how many threads will be blocked on the resource
RC> and how many will be blocked on other things.  In one of my programs which
RC> typically has about 10 threads I use critical sections because I believe
RC> that it would waste CPU time if all threads used semaphores when accessing
RC> certain data structures.  All I have to do is to use DosEnterCritSect()
RC> whenever I'm doing something that requires exclusive access to the data and
RC> I don't need to worry about semaphores in the other threads.  One thing
RC> that makes it easy for me to do this is that all the threads are blocked on
RC> IO for >99.9% of the time, this means that it's quite acceptable for a
RC> thread to lock all the other threads out for a few milliseconds as they are
RC> probably blocked anyway.

 In your specific case, you may be right. But one point in the above 
jumps out at me as one of the major cause of application "hangs" that 
I have diagnosed. You mention that many of your threads are "blocked 
on I/O". It is quite possible to have a thread obtain a ksem (or DD 
semaphore) and then "block" inside an API call (possibly waiting on an
interrupt). Along comes your thread that does an EnterCritSec, and 
then also does the same (or similar) API call that needs the same ksem 
or Device driver sem. This thread now blocks waiting on the sem the 
first one owns. Then the first thread becomes ready to run (interrupt
or other factor) but can't run to release the sem it owns because it
has been blocked by the second thread's critsec. Result, deadlocked
threads. This is very timing sensitive.

 I have seen this more times than I can remember, and the developer 
usually has no idea that it has happened since the "semaphores" are 
within an API (or a developement library of API's, EG:TCPIP, DB/2, 
PM, etc). All he did was use the CritSec. This situation can get even 
worse with OO languages.

 If you want to use this technique, then I recommend that either 
you totally understand all the resources required for *ANY* API's you 
call while within a critsec, or you don't call any API's at all while 
within the critical section. 

RC>    A system call takes more CPU time than 1000 user-mode instructions.  The
RC> fewer OS calls you make the faster your program will run and the lower the
RC> pulse rating will be.                                    

 Granted it takes more cycles (but probably not 1000 times as much), 
but a deaadlocked app doesn't usually perform very well either. The
developers that I have diagnosed these kinds of problems for usually
have very choice words to say about CritSec. Especially when it
involves a device driver (or video device driver) semaphore. The 
whole system can eventually grind to a halt. 
 
 CritSec can be a powerful tool, but you have to realize it's 
limitations. I don't recommend using a jackhammer to pound nails
either, no matter how fast it would be.  


   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