Ns_CritSec(3)            AOLserver Library Procedures            Ns_CritSec(3)


       , Ns_CsDestroy, Ns_CsEnter, Ns_CsInit, Ns_CsLeave - Manage and use
       critical section locks

       #include "ns.h"

       Ns_CsDestroy(Ns_Cs *csPtr)

       Ns_CsEnter(Ns_Cs *csPtr)

       Ns_CsInit(Ns_Cs *csPtr)

       Ns_CsLeave(Ns_Cs *csPtr)

       Critical section locks are used to prevent more than one thread from
       executing a specific section of code at one time. They are implemented
       as "objects", which simply means that memory is allocated to hold the
       lock state. They can also be called "sychronization objects".

       While a thread is executing a critical section of code, all other
       threads that want to execute that same section of code must wait until
       the lock surrounding that critical section has been released.

       This is crucial to prevent race conditions which could put the server
       into an unknown state. For example, if a section of code frees a
       pointer and then decrements a counter that stores how many pointers
       exist, it is possible that the counter value and the actual number of
       pointers may be different. If another section of the server relies on
       this counter and reads it when the pointer has been freed, but the
       counter has not yet been decremented, it could crash the server or put
       it into an unknown state.

       Critical section locks should be used sparingly as they will adversely
       impact the performance of the server or module. They essentially cause
       the section of code they enclose into behaving in a single-threaded
       manner. If a critical section executes slowly or blocks, other threads
       that must execute that section of code will begin to block as well
       until the critical section lock is released.

       You will normally want to wrap sections of code that are used to both
       read and write values, create and destroy pointers and structures or
       otherwise look at or modify data in the system. Use the same named lock
       for both read and write operations on the same data.

       Threads that are waiting for a critical section lock to be released do
       not have to poll the lock. The critical section lock functions use
       thread condition functions to signal when a lock is released.


              Destroy a critical section object.  Note that you would almost
              never need to call this function as synchronization objects are
              typically created at startup and exist until the server exits.

              The underlying objects in the critical section are destroyed and
              the critical section memory returned to the heap.


              Lock a critical section object, initializing it first if needed.
              If the critical section is in use by another thread, the calling
              thread will block until it is no longer so.

              Note that critical sections are recursive and must be exited the
              same number of times as they were entered.


              Initialize a critical section object. Memory will be allocated
              to hold the object's state.


              Unlock a critical section once. A count of threads waiting to
              enter the critical section is kept, and a condition is signaled
              if this is the final unlock of the critical section so that
              other threads may enter the critical section.

       nsd(1), info(n), Ns_MasterLock(3), Ns_MasterUnlock(3),
       Ns_CondDestroy(3), Ns_CondSignal(3), Ns_CondWait(3), Ns_MutexLock(3),

AOLserver                             4.0                        Ns_CritSec(3)