DT> blocked on the resource
RC> and how many will be blocked on other things.  In 
RC> one of my programs which
RC> typically has about 10 threads I use critical 
 DT> sections because I believe
RC> that it would waste CPU time if all threads used 
RC> semaphores when accessing
RC> certain data structures.  All I have to do is to 
 DT> use DosEnterCritSect()
RC> whenever I'm doing something that requires 
RC> exclusive access to the data and
RC> I don't need to worry about semaphores in the other 

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

   This is a bug in OS/2.

   However I won't have this problem as I have always tried to avoid
anything which may cause an OS or API call when in a critical section.  I
generally avoid even doing memory allocation.  My aim is to avoid having a
context switch during the critical section if I can avoid it (because the
reason for a critical section is to lock out other threads quickly for a
small operation which I want to be atomic - if I want to do something
serious then I'll use a semaphore).



   Anyway if SMP hardware goes down in price then I'll have to stop using
critical sections altogether as they will be bad for performance on SMP. 
If I have 3 threads that are runnable on a single-processor then I don't
mind needlessly locking 2 of them out via a critical section that is
designed to lock out other threads - they can't be doing anything useful at
that time-slice anyway.  But on SMP they could be actively doing
something...



  Russell Coker

--- Maximus/2 2.02