Original from  Russell Coker  to Denis Tonn on 10-02-1996
Original Subject: Semaphore

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

 RC>  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 
 RC> 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 
 RC> 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.
 
RC>    This is a bug in OS/2.

 I have seen this opinion expressed before. It may be right. But in 
reality, the above deadlock situations can also occur in "application 
extension" DLLs or runtime libraries and device drivers. Neither are
a "part" of OS/2 directly. In most of the cases I have seen recently,
it is one of the above types of code (non-OS/2) which is the cause of
the "problem". 
 It is a rare programmer that writes *everything* himself nowadays. 
Most prefer to use libraries of routines, either directly linked in or
as DLL's linked at runtime. 

RC>    However I won't have this problem as I have always tried 
RC> to avoid anything which may cause an OS or API call when in 
RC> a critical section.  I generally avoid even doing memory 
RC> allocation.  My aim is to avoid having a context switch 

 Good idea. But unless you are one of the rare individuals, it is 
likely that you will end up using something (without source) written 
by someone else at one time or another. The point still stands that
it is not a good programming practice to use CritSec. It makes the
code harder to extend and maintain even if used properly. 

RC> during the critical section if I can avoid it (because the 
RC> reason for a critical section is to lock out other threads 
RC> quickly for a small operation which I want to be atomic - 
RC> if I want to do something serious then I'll use a 
RC> semaphore).

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


   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