PF> DosEnterCritSec() is a bad practice,  it is NEVER _required_
 PF> (you can always use a sem instead),  and shoots SMP OS/2 in
 PF> the foot.

 MB> In my opinion, DosEnterCritSec() is appropriate where you do not have 
 MB> full control of the source code.  If you are writing a 
 MB> library, you can always require as part of your API 
 MB> that the client check your internal semaphore by 
 MB> calling a function provided for that purpose, but 
 MB> there are some cases where this is not practical.  
 MB> Many C language run-time libraries must stop all 
 MB> threads in the process at some point, often inside low-
 MB> level routines such as malloc().  There really are 
 MB> things which are critical sections, and declaring them 
 MB> as such is a good idea.

I don't agree.  When running with more than one CPU (SMP OS/2),  the crit
sec in malloc() will halt all threads (a time consuming process in itself),
 even if those threads aren't anywhere near malloc (or the CRT in general),
 whereas a mutex sem will only halt those threads that pose a possibility
of confrontation.

There is only one way I have ever used DosEnterCritSec(),  and I didn't
feel real good about it -- but it did prevent me from using a global
variable:

            ...
            DosEnterCritSec();
            WinPostQueueMsg(hwndParent,  WMU_I_AM_DONE ...)
            _endthread();
        }

ie: DosExitCritSec() is never called -- the OS will take care of it when
the thread ends.  The above sequence ensured that the thread's stack was
not freeed before the thread ended (this was pre-OS/2 2.0 code,  where you
had to allocate your own stacks).


--- Maximus/2 3.00