Provided by: aolserver4-dev_4.5.1-18.1_amd64 bug


       , 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

       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


              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), Ns_MutexUnlock(3)