@@LibrariesProcessesandThreads.Synchronization
<GROUP LibrariesProcessesandThreads>
<TITLE Synchronization>
<TOPICORDER 200>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.Debugging
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE Debugging>
<TOPICORDER 100>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE Locked integer manipulation>
<TOPICORDER 200>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclCriticalSection
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclCriticalSection>
<TOPICORDER 300>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclCriticalSectionEx
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclCriticalSectionEx>
<TOPICORDER 400>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclDispatcherObject
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclDispatcherObject>
<TOPICORDER 500>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclEvent
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclEvent>
<TOPICORDER 600>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclMeteredSection
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclMeteredSection>
<TOPICORDER 700>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclMultiReadExclusiveWrite
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclMultiReadExclusiveWrite>
<TOPICORDER 800>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclMutex
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclMutex>
<TOPICORDER 900>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclOptex
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclOptex>
<TOPICORDER 1000>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclSemaphore
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclSemaphore>
<TOPICORDER 1100>
--------------------------------------------------------------------------------
@@LibrariesProcessesandThreads.Synchronization.TJclWaitableTimer
<GROUP LibrariesProcessesandThreads.Synchronization>
<TITLE TJclWaitableTimer>
<TOPICORDER 1200>
--------------------------------------------------------------------------------
@@QueryCriticalSection
<GROUP LibrariesProcessesandThreads.Synchronization.Debugging>
Summary:
  Returns information about a critical section object.
Description:
  QueryCriticalSection returns information about the critical section object specified
  by CS. The function returns a TRTLCriticalSection record which is defined in
  Windows.pas.
Parameters:
  CS - The critical section object about which to return information.
  Info - Receives information about the critical section. See Windows.pas for the declaration of this record, most fields are self-explanatory.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case the contents of the Info parameter are undefined.
Notes:
  This function relies on undocumented information.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@QueryEvent
<GROUP LibrariesProcessesandThreads.Synchronization.Debugging>
Summary:
  Returns information about an event object.
Description:
  QueryEvent returns information about the event object specified by Handle. The
  information is returned in a TEventInfo record and contains members to indicate
  the kind of event and whether it is signaled.
Parameters:
  Handle - Handle of the event object for which you want information.
  Info - Received information about the event. TEventInfo is defined as:   TEventInfo = record     EventType: Longint;     Signaled: LongBool;   end;   The following table describes the members of this record:   <TABLE>
Member     Type      Description
---------  --------  -------------------------------------------------------------------------------------------------------------------
EventType  Longint   If the event is a manual-reset event this member is 0. If the event is an auto-reset event this member is non-zero.
Signaled   LongBool  True if the event is in the signaled state, False if its in the non-signaled state
</TABLE>
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case the contents of the Info parameter are undefined.
Notes:
  This function relies on undocumented information and uses an undocumented API call.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@QueryTimer
<GROUP LibrariesProcessesandThreads.Synchronization.Debugging>
Summary:
  Returns information about a timer object.
Description:
  QueryTimer returns information about the timer object specified by Handle. The
  information is returned in a TTimerInfo record and contains members to indicate
  whether the timer is signaled or how much time remains until the timer becomes
  signaled.
Parameters:
  Handle - Handle of the timer object for which you want information.
  Info - Received information about the timer. TTimerInfo is defined as:   TTimerInfo = record     Remaining: TLargeInteger;     Signaled: LongBool;   end;   The following table describes the members of this record:   <TABLE>
Member     Type           Description
---------  -------------  ----------------------------------------------------------------
Remaining  TLargeInteger  The time, in 100 ns intervals, until the timer becomes signaled.
Signaled   LongBool       True if the timer is currently signaled.
</TABLE>
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case the contents of the Info parameter are undefined.
Notes:
  This function relies on undocumented information and uses an undocumented API call.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@QuerySemaphore
<GROUP LibrariesProcessesandThreads.Synchronization.Debugging>
Summary:
  Returns information about a semaphore object.
Description:
  QuerySemaphore returns information about the semaphore object specified by Handle. The
  information is returned in a TSemaphoreInfo record and contains members to indicate
  the semaphores' current and maximum count.
Parameters:
  Handle - Handle of the semaphore object for which you want information.
  Info - Received information about the event. TSemaphoreInfo is defined as:   TSemaphoreCounts = record     CurrentCount: Longint;     MaximumCount: Longint;   end;    The following table describes the members of this record:   <TABLE>
Member        Type     Description
------------  -------  -------------------------------------------------------------------------------
CurrentCount  Longint  The current count of the semaphore object.
MaximumCount  Longint  The maximum count of the semaphore object as specified when it was constructed.
</TABLE>

Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case the contents of the Info parameter are undefined.
Notes:
  This function relies on undocumented information and uses an undocumented API call.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@QueryMutex
<GROUP LibrariesProcessesandThreads.Synchronization.Debugging>
Summary:
  Returns information about a mutex object.
Description:
  QueryMutex returns information about the mutex object specified by Handle. The
  information is returned in a TMutexInfo record and contains members to indicate
  whether the mutex is signaled and owned.
Parameters:
  Handle - Handle of the mutex object for which you want information.
  Info - Received information about the mutex. TMutexInfo is defined as:   TMutexInfo = record     SignalState: Longint;     Owned: Boolean;     Abandoned: Boolean;   end;   The following table describes the members of this record:   <TABLE>
Member       Type     Description
-----------  -------  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SignalState  Longint  Indicates the state of the mutex. If this member is greater than 0 the mutex is signaled. A value smaller than 0 indicates the number of times the mutex was recursively acquired.
Owned        Boolean  True if the mutex is currently owned by a thread.
Abandoned    Boolean  True if the mutex was abandoned (thread exited while owning the mutex).
</TABLE>
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case the contents of the Info parameter are undefined.
Notes:
  This function relies on undocumented information and uses an undocumented API call.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite
<GROUP LibrariesProcessesandThreads.Synchronization.TJclMultiReadExclusiveWrite>
Summary:
  Allows multiple readers but only one writer.
Description:
  TJclMultiReadExclusiveWrite is a synchronization object similar to a critical section.
  It protects some resource by controlling access to it. Unlike a critical section
  however, a TJclMultiReadExclusiveWrite allows multiple threads access to the
  protected resource. The threads that request access are separated into two logical
  groups called Readers and Writers. The class allows only one writer to have access
  to the resource at any time. All other threads, both readers and writers must
  wait until the resource is released. Readers however can access the resource
  simultaneously. When one or more readers have been granted access, all writers are blocked.
  The distinction between readers and writers is made based on how the threads
  request access to the resource. Readers use the BeginRead and EndRead methods
  while Writers use BeginWrite and EndWrite. It is up to the application to define
  what readers and writers really are.
  In addition to the above, the class allows readers to be promoted to writers and
  it allows the application to tune the access. If you so wish you can have the
  class favor readers over writers, vice versa or treat them equally. Note that
  if you have the class favor one over the other than the 'other' may never get
  access to the resource depending on the details of your application and pure
  coincidence (due to timing issues which are beyond control of the class).
  Note that the implementation of this class was inspired mainly by Jeffrey Richters
  CMREW class presented in his book "Programming applications for Microsoft Windows,
  4th edition".
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.Create
Summary:
  Creates an instance of TJclMultiReadExclusiveWrite.
Description:
  Creates an instance of TJclMultiReadExclusiveWrite.
Parameters:
  Preferred - Denotes whether the class should favor readers over writers, vice versa or treat them equally. See TMrewPreferred for more information.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.Destroy
Summary:
  Destroys the instance of TJclMultiReadExclusiveWrite.
Description:
  Destroys the instance of TJclMultiReadExclusiveWrite.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.BeginRead
Summary:
  Allows a thread read-access to the protected resource, blocking until the access can be granted.
Description:
  BeginRead allows a thread to gain read-access to the protected resource. This
  method will block the calling thread until read-access can be granted. After the
  thread has been granted access other threads may request, and be granted, read-access
  to the protected resource but write access requests will be denied until all
  threads that hold read-access have finished using the resource. A thread which
  has been granted read-access must eventually call EndRead to signal that it
  has finished using the resource. Note that read-access can be promoted to
  write-access by calling BeginWrite, however, both the calls to BeginRead and
  BeginWrite must have a matching call to EndRead and EndWrite respectively.
  It is safe to call BeginRead while already holding read-access, it merely
  increments a recursion count. If you call BeginRead multiple times you must also
  call EndRead multiple times. That is, the calls to BeginRead and
  EndRead must be balanced. Note that even if the class has only granted access
  to readers while BeginRead is called, the calling thread may still be blocked
  depending on the Preferred value passed to the constructor.
See also:
  EndRead
  BeginWrite
  EndWrite
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.BeginWrite
Summary:
  Allows a thread write-access to the protected resource, blocking until the access can be granted.
Description:
  BeginWrite allows a thread to gain write-access to the protected resource. This
  method will block the calling thread until write-access can be granted. After a
  thread has been granted write-access, all other threads requesting access, either
  read or write, will be denied access until the thread currently holding write-access
  calls EndWrite.
  Note that it is legal to request read-access while holding write-access, however,
  the thread will not be granted read-access, instead its recursion count is
  incremented and write-access is preserved. It is safe to call BeginWrite while
  already holding write-access, it merely increments a recursion count. If you call
  BeginWrite multiple times you must also call EndWrite multiple times.
  That is, the calls to BeginWrite and EndWrite must be balanced.
Notes:
  Warning! Calling BeginWrite while the thread already owns a read lock causes the thread to temporarily give up it's read lock altogether. Therefore it is not safe to assume that the resource is unchanged when you "promote" a read lock to a write lock. This is necessary to prevent a dead lock situation where two threads both attempt to promote a read lock.
See also:
  EndRead
  BeginRead
  EndWrite
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.EndRead
Summary:
  Signals that the thread has finished reading from the resource.
Description:
  EndRead signals that the thread holding read-access to the protected resource has
  finished reading from the resource. You must call EndRead once for each time you
  called BeginRead. Even though it is safe to call EndRead while not
  holding read-access you should not do so. The same is true for calling EndWrite
  while currently holding read-access. Once all threads have released their
  read-access locks, currently blocked threads are released. The exact algorithm
  used to determine which threads to release depends on the Preferred value passed
  to the constructor.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMultiReadExclusiveWrite.EndWrite
Summary:
  Signals that the thread has finished writing to the resource.
Description:
  EndWrite signals that the thread holding write-access to the protected resource has
  finished writing to the resource. You must call EndWrite once for each time you
  called BeginWrite. Even though it is safe to call EndWrite while not
  holding write-access you should not do so. The same is true for calling EndRead
  while currently holding write-access. Once the calls to BeginWrite and EndWrite
  are balanced so that the write-lock is released, other blocked threads are
  released. The exact algorithm used to determine which threads to release depends
  on the Preferred value passed to the constructor.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex
<GROUP LibrariesProcessesandThreads.Synchronization.TJclOptex>
Summary:
  Optimized Mutex
Description:
  Optex stands for Optimized Mutex. It's a synchronization object which holds middle
  ground between a Win32 Mutex and a Critical Section. It provides the speed and
  functionality similar to a critical section but has the additional property
  that it can be used across process boundaries (like a mutex). This code was originally
  written by Jeffrey Richter and is presented, and fully explained, in his excellent,
  must-have book "Programming applications for Microsoft Windows, 4th edition".
  This book was formerly titled "Advanced Windows". The Object Pascal class that
  is included in the JCL is almost a straight port from that code. Any bugs
  in this class were most likely introduced by these modifications or an incorrect
  port.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Existed
Summary:
  Returns whether the optex existed.
Description:
  The Existed property returns whether the Optex was newly created (Existed is False)
  or already existed during construction (Existed is True). In this latter case the
  Optex was already created by another process. This tells you only that the Optex
  existed during execution of the constructor. There is no way to find out whether
  another process still has the Optex open.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Name
Summary:
  Name of the object.
Description:
  The Name property returns the name of the Optex as specified in the constructor.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.SpinCount
Summary:
  Sets the spincount.
Description:
  The SpinCount property allows you to query the current value of the spincount of
  the optex or to set a new value. Note that the spincount value is shared between
  all processes that use the same optex. This is not True for distinct optex objects.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.UniProcess
Summary:
  Returns whether the optex can be shared between processes.
Description:
  Returns whether the optex can be used in the process only or can be shared
  between processes. This is directly related to whether or not you specified a
  name for the optex during construction. If you specified a name, the optex can
  be shared and this property will be False, otherwise it will be True. Note that
  this tells you nothing about whether or not multiple processes are actually using
  the optex, only if they can.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Create
Summary:
  Creates an instance of the Optex class.
Description:
  The Create constructor creates an instance of the Optex class. If you intend to
  use the optex in the current process only you should specify an empty string for
  the name parameter. If you want to share it between processes you must give the
  optex a name.
Parameters:
  Name - Name for the Optex. When you want to share the Optex between multiple processes you must give it a name. The second process can then open the Optex by calling Create with the same name.
  SpinCount - The spincount for the optex object. Conceptually the optex will try to attempt ownership of the optex for SpinCount number of times when the Enter method is called. If the optex is still not available after these attempts the thread enters a wait state until the optex is released. On a single-processor system this parameter is ignored and the optex will use 0 internally. This means the optex will never spin before waiting on the kernel event. This makes sense since the optex could never be released while the thread was spinning (and thus monopolizing the processor). Note that the spincount is effective for all processes that use the same, named optex. If one process changes the spincount this takes effect in all the other processes immediately as well.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Destroy
Summary:
  Destroys the Optex instance.
Description:
  The Destroy destructor destroys the Optex instance for which it is called. If the
  Optex is shared between multiple processes only this instance is destroyed and
  other processes can continue to use the Optex.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Enter
Summary:
  Enters the Optex.
Description:
  Enter attempts to get access to the optex, this is referred to as
  acquiring ownership of the optex. Only one thread can own the optex
  at any time. If the optex is currently owned by a different
  thread the function blocks until the critical section becomes free. After
  acquiring ownership of the optex you must release it as soon as you
  are done with it by calling the Leave method. Although only one
  thread can own the optex, a single thread can own the optex more than once.
  This means you can call Enter multiple times. However, calls to Enter
  and Leave must be balanced: you must call Leave for each time you call Enter.
  Note that if the process is running on a multiprocessor system and the optex
  is currently owned by anther thread, the Enter method spins in a loop SpinCount
  number of times, trying to acquire the optex. If the optex becomes available
  before the loop terminated the thread acquires the optex and returns. On a
  single-processor system the method only tries one time.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.Leave
Summary:
  Releases ownership of the optex.
Description:
  The Release method releases ownership of the optex previously acquired
  by a call to the Enter method. After a call to Release the optex
  is free to be acquired by a different thread. If you called Enter multiple
  times the optex will not be released until the last, balancing call
  to Release.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclOptex.TryEnter
Summary:
  Attempts to Enter the critical section.
Description:
  TryEnter attempts to acquire ownership of the optex object. However, unlike
  the Enter method, this method immediately returns if the optex cannot
  be acquired the first time around.
Result:
  If ownership of the optex object is acquired the function returns
  True. If ownership could not be acquired because the optex was already
  owned by a different thread the function returns False. In this latter case you
  must take care not to call Release.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclWaitableTimer
<GROUP LibrariesProcessesandThreads.Synchronization.TJclWaitableTimer>
Summary:
  Wrapper for a Win32 Waitable Timer object.
Description:
  TJclWaitableTimer is a wrapper for a Win32 Waitable Timer object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclWaitableTimer.Cancel
Summary:
  Deactivates the waitable timer.
Description:
  The Cancel method stops the timer before it can be set to the signaled state and
  cancels any outstanding APC's. Threads that are waiting on the timer remain waiting
  until the timer is reactivated with SetTimer. If the Timer is already
  in the signaled state it remains signaled.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case you can call GetLastError to get extended error information.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclWaitableTimer.SetTimer
Summary:
  Activates the timer.
Description:
  The SetTimer method activates the timer. When the DueTime arrives the timer is
  set to the signaled state and threads waiting for the timer using one of the
  WaitXxx functions become eligible for execution. If the timer was already active
  (in its signaled state) the timer is reactivated with the new parameters without
  releasing any waiting threads.
Parameters:
  DueTime - Specifies when the timer becomes signaled. A positive value indicates an absolute time in UTC and TFileTime format (you must convert a time expressed in UTC from a TFileTime to an Int64). A negative value indicates a relative time in 100 nanosecond intervals.
  Period - Period of the timer in milliseconds. A 0 period causes the timer to become signaled only once while a value greater than 0 causes the timer to periodically become signaled. Note that a periodic manual-reset timer remains in the signaled state until it is explicitly reset.
  Resume - Specifies whether to restore a system in suspended power conservation mode when the timer state is set to signaled.
Result:
  If the function succeeds the result is True, otherwise it is False. In the latter
  case you can call GetLastError to get extended error information. Note that if
  you set Resume to True on a platform which doesn't support this, the method
  succeeds (returns True) but calling GetLastError will return ERROR_NOT_SUPPORTED.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclWaitableTimer.SetTimerApc
Summary:
  Activates the timer.
Description:
  The SetTimerApc method activates the timer. When the DueTime arrives the timer is
  set to the signaled state and threads waiting for the timer using one of the
  WaitXxx functions become eligible for execution. Additionally the specified Apc
  routine is called in the context of the thread that called SetTimerApc.
  If the timer was already active (in its signaled state) the timer is reactivated
  with the new parameters without releasing any waiting threads.
  Count=5
  1=DueTime:Int64=Specifies when the timer becomes signaled. A positive value
  indicates an absolute time in UTC and TFileTime format (you must convert a time
  expressed in UTC from a TFileTime to an Int64). A negative value indicates a
  relative time in 100 nanosecond intervals.
  2=Period:Longint=Period of the timer in milliseconds. A 0 period causes the timer
  to become signaled only once while a value greater than 0 causes the timer to
  periodically become signaled. Note that a periodic manual-reset timer remains
  in the signaled state until it is explicitly reset.
  3=Resume:Boolean=Specifies whether to restore a system in suspended power
  conservation mode when the timer state is set to signaled.
  4=Apc:TFNTimerAPCRoutine=Application defined completion routine which is called
  when the timer becomes signaled.
  5=Arg:Pointer=Application defined value which is passed to the completion routine.
Result:
  If the function succeeds the result is True, otherwise it is False. In the latter
  case you can call GetLastError to get extended error information. Note that if
  you set Resume to True on a platform which doesn't support this, the method
  succeeds (returns True) but calling GetLastError will return ERROR_NOT_SUPPORTED.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TFNTimerAPCRoutine
<GROUP LibrariesProcessesandThreads.Synchronization.TJclWaitableTimer>
Summary:
  Timer callback routine.
Description:
  TFNTimerAPCRoutine is used as the callback routine for waitable timers. The procedure
  is executed when the waitable timer becomes signaled in the context of the thread
  that activated the timer using the SetTimer or SetTimerApc method. However, that
  thread must be in an alertable state or the completion routine will be cancelled.
Parameters:
  Arg - Application defined value as passed to SetTimerApc.
  TimerLow - Low order 32-bits of the UTC based time when the timer was signaled. This value corresponds to the dwLowDateTime value of a TFileTime record.
  Apc - High order 32-bits of the UTC based time when the timer was signaled. This value corresponds to the dwHighDateTime value of a TFileTime record.
See also:
  SetTimerApc
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclWaitableTimer.Create
Summary:
  Creates an instance of a TJclWaitableTimer object and the underlying Win32 waitable timer object.
Description:
  Creates an instance of a TJclWaitableTimer object and the underlying Win32 waitable timer object.
Parameters:
  SecAttr - Pointer to a TSecurityAttributes record that specifies the security attributes of the new waitable timer object such as whether it can be inherited. If you specify nil the Handle cannot be inherited and the waitable timer receives a default security descriptor.
  Manual - If True the timer acts as a manual-reset notification timer. If False the timer acts as a synchronization timer.
  Name - Name of the waitable timer object, can be empty. If a waitable timer already exists on the system with the same name, the waitable timer is opened with TIMER_ALL_ACCESS. If the waitable timer cannot be opened the constructor fails by raising an EJclWaitableTimerError exception. If no waitable timer with the specified name exists, the waitable timer is created with that name. If a named object already exists with the specified name but it is not a waitable timer, the constructor fails by raising an EJclWaitableTimerError exception.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclWaitableTimer.Open
Summary:
  The Open constructor attempts to open the existing named waitable timer specified with Name.
Description:
  Opens an existing, named waitable timer. If the waitable timer object does not exist, or the calling
  thread does not have sufficient access to open the waitable timer object, the constructor
  fails by raising an EJclWaitableTimerError exception.
Parameters:
  Access - Requested access to the timer object. This can be a combination of the following values:

<TABLE>
Value               Meaning
------------------  --------------------------------------------------------------------------------------------------------------------------------
TIMER_ALL_ACCESS    Specifies all possible access rights for the timer object.
TIMER_MODIFY_STATE  Enables use of the timer handle in the SetTimer and Cancel methods to modify the timer's state.
TIMER_QUERY_STATE   Reserved for future use.
SYNCHRONIZE         Windows NT/2000: Enables use of the timer handle in any of the wait methods to wait for the timer's state to be signaled.
</TABLE>

  Inheritable - Specifies whether the Handle of the waitable timer object can be inherited by child processes.
  Name - Name of the waitable timer object to open.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclSemaphore
<GROUP LibrariesProcessesandThreads.Synchronization.TJclSemaphore>
Summary:
  Wrapper for a Win32 Semaphore object.
Description:
  TJclSemaphore is a wrapper for a Win32 Semaphore object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclSemaphore.Release
Summary:
  Increases the semaphore's count.
Description:
  The Release method increases the count of the semaphore object by the specified
  amount, but never increases past the maximum count as specified during construction.
Parameters:
  ReleaseCount - The amount by which the semaphore's count should be increased. The value must be greater than 0. If the increase would cause the count to exceed the maximum the method fails (returns False) and the current count remains unchanged.
Result:
  If the function succeeds the result is True, otherwise the result is False. In
  the latter case you can call GetLastError to get extended error information.
See also:
  ReleasePrev
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclSemaphore.ReleasePrev
Summary:
  Increases the semaphore's count.
Description:
  The Release method increases the count of the semaphore object by the specified
  amount, but never increases past the maximum count as specified during construction.
Parameters:
  ReleaseCount - The amount by which the semaphore's count should be increased. The value must be greater than 0. If the increase would cause the count to exceed the maximum the method fails (returns False) and the current count remains unchanged.
  PrevCount - Receives the previous count of the semaphore, before the increase. If the function fails the value of this parameter is undefined.
Result:
  If the function succeeds the result is True, otherwise the result is False. In
  the latter case you can call GetLastError to get extended error information.
See also:
  Release
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclSemaphore.Create
Summary:
  Creates an instance of a TJclSemaphore object and the underlying Win32 semaphore object.
Description:
  Creates an instance of a TJclSemaphore object and the underlying Win32 semaphore object.
Parameters:
  SecAttr - Pointer to a TSecurityAttributes record that specifies the security attributes of the new semaphore object such as whether it can be inherited. If you specify nil the Handle cannot be inherited and the semaphore receives a default security descriptor.
  Initial - Initial count of the semaphore object. This value must be between 0 and Maximum (both inclusive). The state of a semaphore is signaled when its count is zero and nonsignaled otherwise. A successful wait operation on a semaphore decreases the count of the semaphore by one. The count is increased by a specified amount by using the Release method but cannot be increased beyond the specified Maximum.
  Maximum - Maximum count of the semaphore object. Must be greater than 0.
  Name - Name of the semaphore object, can be empty. If a semaphore already exists on the system with the same name, the semaphore is opened with SEMAPHORE_ALL_ACCESS. If the semaphore cannot be opened the constructor fails by raising an EJclSemaphoreError exception. If no semaphore with the specified name exists, the semaphore is created with that name. If a named object already exists with the specified name but it is not a semaphore, the constructor fails by raising an EJclSemaphoreError exception.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclSemaphore.Open
Summary:
  The Open constructor attempts to open the existing named semaphore specified with Name.
Description:
  Opens an existing, named semaphore. If the semaphore object does not exist, or the calling
  thread does not have sufficient access to open the semaphore object, the constructor
  fails by raising an EJclSemaphoreError exception.
Parameters:
  Access - Requested access to the semaphore object. This can be a combination of the following values:

<TABLE>
Access                  Description
----------------------  ----------------------------------------------------------------------------------------------------------------------------------------
SEMAPHORE_ALL_ACCESS    Specifies all possible access flags for the semaphore object.
SEMAPHORE_MODIFY_STATE  Enables use of the semaphore handle in the Release method to modify the semaphore's count.
SYNCHRONIZE             Windows NT/2000: Enables use of the semaphore handle in any of the wait methods to wait for the semaphore's state to be signaled.
</TABLE>

   - Specifies whether the Handle of the semaphore object can be inherited by child processes.
  Name - Name of the semaphore object to open.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMutex
<GROUP LibrariesProcessesandThreads.Synchronization.TJclMutex>
Summary:
  Wrapper for a Win32 Mutex object.
Description:
  TJclMutex is a wrapper for a Win32 Mutex object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMutex.Create
Summary:
  Creates an instance of a TJclMutex object and the underlying Win32 mutex object.
Description:
  Creates an instance of a TJclMutex object and the underlying Win32 mutex object.
Parameters:
  SecAttr - Pointer to a TSecurityAttributes record that specifies the security attributes of the new Mutex object such as whether it can be inherited. If you specify nil the Handle cannot be inherited and the Mutex receives a default security descriptor.
  InitialOwner - Set to True if you want immediate ownership of the mutex object. Note that initial ownership will only be granted if the call actually creates the mutex. If the named mutex already exists the constructor opens the mutex but you will not have ownership. Use the Existed property to determine whether the constructor created or opened the named mutex. This is a non-issue for unnamed mutexes or calls for which this parameter is False.
  Name - Name of the Mutex object, can be empty. If a mutex already exists on the system with the same name, the mutex is opened with MUTEX_ALL_ACCESS. If the mutex cannot be opened the constructor fails by raising an EJclMutexError exception. If no mutex with the specified name exists, the mutex is created with that name. If a named object already exists wit the specified name but it is not a mutex, the constructor fails by raising an EJclMutexError exception.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMutex.Open
Summary:
  The Open constructor attempts to open the existing named mutex specified with Name.
Description:
  Opens an existing, named mutex. If the mutex object does not exist, or the calling
  thread does not have sufficient access to open the mutex object, the constructor
  fails by raising an EJclMutexError exception.
Parameters:
  Access - Requested access to the Mutex object. This can be a combination of the following values:

<TABLE>
Access            Description
----------------  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
MUTEX_ALL_ACCESS  Specifies all possible access flags for the mutex object.
SYNCHRONIZE       Windows NT/2000: Enables use of the mutex handle in any of the wait functions to acquire ownership of the mutex, or in the ReleaseMutex function to release ownership.
</TABLE>

  Inheritable - Specifies whether the Handle of the Mutex object can be inherited by child processes.
  Name - Name of the Mutex object to open.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMutex.Release
Summary:
  Releases ownership of the mutex.
Description:
  The Release method release ownership of the mutex which was previously obtained
  by using one of the WaitXxx methods. Note that although only one thread can own
  a mutex at any time, a single thread can own the mutex multiple times by calling
  one of the WaitXxx methods multiple times. You must balance the calls to WaitXxx
  and Release, meaning you must call Release once for each time you call WaitXxx.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case, which is usually a result of not owning the mutex, you can call GetLastError
  to get extended error information.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx
<GROUP LibrariesProcessesandThreads.Synchronization.TJclCriticalSectionEx>
Summary:
  Wrapper for a Win32 critical section object
Description:
  TJclCriticalSection is a wrapper for a Win32 critical section object which surfaces
  all functionality, including functionality not available in Windows 95. To use
  TJclCriticalSectionEx the target system must be running Windows NT 4 with service
  pack 3 or better or Windows 98. Note however that the TryEnter, GetSpinCount, and
  SetSpinCount methods are not implemented in Windows 98.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx.CreateEx
Summary:
  Creates an instance of a TJclCriticalSectionEx object.
Description:
  The CreateEx constructor creates an instance of a TJclCriticalSection object
  and initializes the underlying Win32 critical section object. The parameters
  allow you to specify a spincount for the critical section and you can specify
  whether the internally used event object must be preallocated (see below). The
  Create constructor is overloaded for TJclCriticalSectionEx and simply calls
  CreateEx with 4000 and False for SpinCount and NoFailEnter respectively.
Parameters:
  SpinCount - The spincount for the critical section object. Conceptually the critical section will try to attempt ownership of the critical section for SpinCount number of times when the Enter method is called. If the critical section is still not available after these attempts the thread enters a wait state until the critical section is released. On a single-processor system this parameter is ignored and the critical section will use 0 internally. This means the critical section will never spin before waiting on a kernel event. This makes sense since the critical section could never be released while the thread was spinning (and thus monopolizing the processor).
  NoFailEnter - If True the kernel event object which is used when a thread must enter a wait state because the critical section is not available, is preallocated thereby guaranteeing that the Enter method does not fail, even in low memory situations.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx.TryEnter
Summary:
  Attempts to Enter the critical section.
Description:
  TryEnter attempts to acquire ownership of the critical section object. However,
  unlike the Enter method,
  this method immediately returns if the critical section cannot be acquired.  Note this
  method is not supported on Windows 98.
Result:
  If ownership of the critical section object is acquired the function returns
  True. If ownership could not be acquired because the critical section was already
  owned by a different thread the function returns False. In this latter case you
  must take care not to call Release.
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx.GetSpinTimeOut
Summary:
  Returns the system setting of the critical section timeout.
Description:
  GetSpinTimeOut returns the system's global critical section timeout value. This
  value determines after which interval an attempt to enter a critical section
  times out. The default setting is about 30 days.
Result:
  The systems critical section timeout interval in seconds.
See also:
  SetSpinTimeOut
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx.SetSpinTimeOut
Summary:
  Sets the system's critical section timeout value.
Description:
  SetSpinTimeOut sets the system's global critical section timeout value. This
  value determines after which interval an attempt to enter a critical section
  times out. The default setting is about 30 days. Note that this value affects
  all threads on the entire system. Do not set this value too low since it might
  negatively affect threads that normally wait longer than the timeout interval
  and do not expect to timeout.
Parameters:
  Value - The new critical section timeout interval in seconds.
See also:
  GetSpinTimeOut
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSectionEx.SpinCount
Summary:
  Sets the spincount for the critical section.
Description:
  SpinCount allows you to query or set the critical section's spincount value.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection
<GROUP LibrariesProcessesandThreads.Synchronization.TJclCriticalSection>
Summary:
  Wrapper for a Win32 critical section object
Description:
  TJclCriticalSection is a wrapper for a Win32 critical section object which surfaces
  only functionality common to all Win32 implementations. Windows 98 and Windows NT
  introduced some additional functionality which is only available in the
  TJclCriticalSectionEx class.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection.Create
Summary:
  Creates an instance of a TJclCriticalSection object.
Description:
  The create constructor creates an instance of a TJclCriticalSection object and
  initializes the underlying Win32 critical section object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection.CreateAndEnter
Summary:
  Creates an instance of a TJclCriticalSection object and enters it.
Description:
  The CreateAndEnter class method creates an instance of TJclCriticalSection and
  Enters it in an atomic, and therefor thread safe, manner. The newly created
  critical section is then assigned to the CS parameter. The method does not return
  until ownership of the critical section can be obtained. This routine is handy in
  situations where you use a lazy creation approach (that is don't create the
  ciritical section until it is actually needed) and there's a possibility that
  multiple threads could attempt to create the critical section simultanuously.
Parameters:
  CS - Variable which receives a reference to the newly created critical section object. It is valid for the parameter to contain a reference to an already created critical section. In that case the method merely attempts to Enter the existing critical section. If the parameter does not contain a valid reference it must be nil (declaring a variable as a global variable or object data field will ensure the variable is initialized to nil).
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection.Destroy
Summary:
  Destroys the TJclCriticalSection object.
Description:
  The Destroy destructor releases the underlying Win32 critical section object and
  destroys the TJclCriticalSection object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection.Enter
Summary:
  Enters the critical section.
Description:
  Enter attempts to get access to the critical section, this is referred to as
  acquiring ownership of the critical section. Only one thread can own the critical
  section at any time. If the critical section is currently owned by a different
  thread the function blocks until the critical section becomes free. After
  acquiring ownership of the critical section you must release it as soon as you
  are done with it by calling the Leave method. Although only one
  thread can own the critical section, a single thread can own the critical section
  more than once. This means you can call Enter multiple times. However, calls to Enter
  and Leave must be balanced: you must call Leave for each time you call Enter.
Notes:
  In extremely low-memory situations a call to Enter may fail by raising an exception. If you cannot tolerate a failure of Enter you should use TJclCriticalSectionEx instead.
See also:
  Leave
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclCriticalSection.Leave
Summary:
  Releases ownership of the critical section.
Description:
  The Release method releases ownership of the critical section previously acquired
  by a call to the Enter method. After a call to Release the critical
  section is free to be acquired by a different thread. If you called Enter multiple
  times the critical section will not be released until the last, balancing call
  to Release.
Notes:
  If you call Release while you don't currently own the critical section, the state of the critical section object becomes corrupted and threads waiting for ownership may be blocked forever.
See also:
  Enter
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent
<GROUP LibrariesProcessesandThreads.Synchronization.TJclEvent>
Summary:
  Wrapper for the Win32 Event object.
Description:
  TJclEvent is a wrapper for a Win32 Event object.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent.Pulse
Summary:
  Pulses the Event object.
Description:
  Pulse sets the Event to the signaled state and back to nonsignaled in one single
  operation releasing the appropriate waiting threads in between. For a manual-reset
  event, all waiting threads are released before returning the Event to the nonsignaled
  state. For an auto-reset event, only one waiting thread is released. If no threads
  are waiting the function merely resets the Event to the nonsignaled state.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case you can call GetLastError to get extended error information.
See also:
  ResetEvent
  SetEvent
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent.ResetEvent
Summary:
  Resets the Event to the nonsignaled state.
Description:
  ResetEvent resets the Event to the nonsignaled state thereby blocking all waiting
  threads. This is only useful for a manual-reset event which has to be explicitly
  set or reset. Auto-reset events are automatically reset to the nonsignaled state
  whenever a thread successfully waited on it.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case you can call GetLastError to get extended error information.
See also:
  Pulse
  SetEvent
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent.SetEvent
Summary:
  Sets the Event to the signaled state.
Description:
  SetEvent sets the Event to the signaled state. Manual-reset events remain in the
  signaled state until explicitly reset by using ResetEvent. All threads
  subsequently calling one of the wait functions are released immediately. For
  auto-reset events the state remains signaled until one thread is released from
  waiting on this event.
Result:
  If the function succeeds it returns True, otherwise it returns False. In the latter
  case you can call GetLastError to get extended error information.
See also:
  Pulse
  ResetEvent
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent.Create
Summary:
  Creates an instance of a TJclEvent object.
Description:
  Create creates an instance of a TJclEvent object.
Parameters:
  SecAttr - Pointer to a TSecurityAttributes record that specifies the security attributes of the new Event object such as whether it can be inherited. If you specify nil the Handle cannot be inherited and the Event receives a default security descriptor.
  Manual - Specifies whether a manual-reset or auto-reset event is created. If True (manual-reset) you must use the ResetEvent method to manually reset the state of the event to nonsignaled. If False (auto-reset) the system automatically sets the state of the Event object to non-signaled when a thread successfully waited on the event.
  Signaled - Specifies the initial state of the Event. If True the Event is created in the signaled state, if False it is created in the non-signaled state.
  Name - Name of the Event object, can be empty. If an event already exists on the system with the same name, the event is opened with EVENT_ALL_ACCESS. If the Event cannot be opened the constructor fails by raising an EJclEventError exception. If no Event with the specified name exists, the Event is created with that name. If a named object already exists wit the specified name but it is not an event, the constructor fails by raising an EJclEventError exception.
See also:
  Open
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclEvent.Open
Summary:
  The Open constructor attempts to open the existing named event specified with Name.
Description:
  Opens an existing, named event. If the Event object does not exist, or the calling
  thread does not have sufficient access to open the Event object, the constructor
  fails by raising an EJclEventError exception.
Parameters:
  Access - Requested access to the Event object. This can be a combination of the following values:

<TABLE>
Access              Description
------------------  ----------------------------------------------------------------------------------------------------------------------------------
EVENT_ALL_ACCESS    Specifies all possible access flags for the event object.
EVENT_MODIFY_STATE  Enables modification of the event's state with the SetEvent and ResetEvent methods.
SYNCHRONIZE         Windows NT/2000: Enables use of the event handle in any of the wait functions to wait for the event's state to be signaled.
</TABLE>

  Inheritable - Specifies whether the Handle of the Event object can be inherited by child processes.
  Name - Name of the Event object to open.
See also:
  Create
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject
<GROUP LibrariesProcessesandThreads.Synchronization.TJclDispatcherObject>
Summary:
  Base class for kernel synchronization objects.
Description:
  TJclDispatcherObject is the base class for all kernel synchronization objects,
  which are also known as dispatcher objects, hence the name. It has provisions
  for the storage of a handle to the object and automatically releases the handle
  when the object is destructed. Additionally it provides methods to wait on the
  object which are common to all dispatcher object derivatives.
Notes:
  There are several non-kernel synchronization objects that do not derive from TJclDispatcherObject. Examples are the TJclCriticalSection and TJclOptex.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.Existed
Summary:
  Indicates whether the object existed.
Description:
  The Existed property denotes whether the dispatcher object already existed when
  it was created. This property is True if:
    
      * You successfully used the Open constructor.
      * If an object with the Name specified in the constructor already existed
          somewhere on the system and you have been granted access to that object.
    
  If you create a named object which doesn't exist, the object is created and Existed
  will be False. Unnamed object always result in Existed being False.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.Handle
Summary:
  Handle to the dispatcher object being wrapped.
Description:
  The handle property contains the handle to the underlying dispatcher object. You
  could use this in a call to WaitForMultipleObjects or to duplicate the Handle. Never
  manually close the handle by calling CloseHandle, the class does this automatically
  in the destructor.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.Name
Summary:
  The name of the object.
Description:
  Name contains the name of the object as specified in the constructor.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclWaitResult
<GROUP LibrariesProcessesandThreads.Synchronization.TJclDispatcherObject>
Summary:
  Enumeration used as the method result by WaitFor, WaitForever and WaitAlertable.
Description:
  Enumeration used as the method result by WaitFor, WaitForever and WaitAlertable.
Donator:
  Marcel van Brakel
@@TJclWaitResult.wrAbandoned
  Only applicable if the object is a mutex which was not released by the owning thread before the thread exited. The calling thread has been granted ownership of the mutex which is set to nonsignaled.
@@TJclWaitResult.wrError
  An error occurred. You can call GetLastError to get more information about why the method failed.
@@TJclWaitResult.wrIoCompletion
  One or more I/O completion routines were queued. Only applicable to WaitAlertable.
@@TJclWaitResult.wrSignaled
  The object was, or became, signaled.
@@TJclWaitResult.wrTimeout
  The timeout interval expired. This is not a successful wait.
--------------------------------------------------------------------------------
@@TJclDispatcherObject.SignalAndWait
Summary:
  Signals another object and then blocks until the object becomes signaled or the timeout expires.
Description:
  SignalAndWait signals the specified object (Obj) and checks the state of the object this
  method belongs to, if it is non-signaled the calling thread enters an alertable
  wait-state until one of the following occurs:
   
    * The object becomes signaled.
    * The time-out interval expires.
    * An I/O completion routine or asynchronous procedure call is queued to the thread.
   
  If the object is signaled, or one of the above mentioned events occur while in a
  wait-state, the method returns and the calling thread is allowed to continue
  execution.
  Note that successfully waiting on a dispatcher object can, depending on the object,
  modify the state of the underlying object. For example, the count of a semaphore
  is decreased by one before the method returns. See the individual synchronization
  classes and the Platform SDK for details.
Parameters:
  Obj - The object to signal before waiting on the object for which this method is called. The object to signal can be a Mutex, Event or Semaphore to which you must have the appropriate access.
  TimeOut - Interval, in milliseconds, the method waits on an object. If the object does not become signaled before the interval has expired, the method returns.
  Alertable - If False the method blocks until either the object becomes signaled or the timeout expires. If True the calling thread enters an alertable wait-state until one of the aforementioned events occur or an I/O Completion routine or APC is queued for the thread.
Result:
  The result indicates success or failure and is of type TJclWaitResult. This method can
  return any of the members of the enumeration. See TJclWaitResult for the details.
Note:
  For Windows 9x, Windows Millenium Edition and Windows NT versions below 4, the
  internally called Windows API function SignalObjectAndWait is not available.
  In this case the result is wrError.
See also:
  WaitFor
  WaitForever
  WaitForMultipleObjects
  WaitAlertableForMultipleObjects
Donator:
  Marcel van Brakel
Contributor:
  Anonymous
--------------------------------------------------------------------------------
@@TJclDispatcherObject.WaitAlertable
Summary:
  WaitAlertable blocks until the object becomes signaled or the timeout expires.
Description:
  WaitAlertable checks the state of the object, if it is non-signaled the calling
  thread enters an alertable wait-state until one of the following occurs:
   
    * The object becomes signaled.
    * The time-out interval expires.
    * An I/O completion routine or asynchronous procedure call is queued to the thread.
   
  If the object is signaled, or one of the above mentioned events occur while in a
  wait-state, the method returns and the calling thread is allowed to continue
  execution.
  Note that successfully waiting on a dispatcher object can, depending on the object,
  modify the state of the underlying object. For example, the count of a semaphore
  is decreased by one before the method returns. See the individual synchronization
  classes and the Platform SDK for details.
Parameters:
  TimeOut - Interval, in milliseconds, the method waits on an object. If the object does not become signaled before the interval has expired, the method returns.
Result:
  The result indicates success or failure and is of
  type TJclWaitResult. This method can
  return any of the members of the enumeration. See TJclWaitResult for the details.
See also:
  WaitFor
  WaitForever
  WaitForMultipleObjects
  WaitAlertableForMultipleObjects
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.WaitFor
Summary:
  Blocks until the object becomes signaled or the timeout expires.
Description:
  WaitFor checks the state of the object, if it is non-signaled the calling thread
  enters a wait state until one of the following occurs:
    
      * The object becomes signaled.
      * The time-out interval expires.
    
  If the object is signaled, or one of the above mentioned events occurs, the function
  returns and the thread is allowed to continue execution.
  Note that successfully waiting on a dispatcher object can, depending on the object,
  modify the state of the underlying object. For example, the count of a semaphore
  is decreased by one before the method returns. See the individual synchronization
  classes and the Platform SDK for details.
Parameters:
  TimeOut - Interval, in milliseconds, the method waits on an object. If the object does not become signaled before the interval has expired, the method returns. If you specify a 0 timeout the method tests the state of the object and immediately returns. You can specify INFINITE to wait forever or use WaitForever instead.
Result:
  The result indicates success or failure and is of
  type TJclWaitResult. This type is shared
  between all WaitXxx functions and as such not all members of this enumeration can
  be returned from this method. Valid ones are wrError, wrAbandoned, wrTimeOut and
  wrSignaled. See TJclWaitResult for the details.
Notes:
  This method results in non-alertable wait state while the object is not signaled. Use WaitAlertable to enter an alertable wait state.
See also:
  WaitAlertable
  WaitForever
  WaitForMultipleObjects
  WaitAlertableForMultipleObjects
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.WaitForever
Summary:
  Blocks until the object becomes signaled.
Description:
  WaitForever checks the state of the object, if it is non-signaled the calling
  thread enters a wait state until the object becomes signaled. If the object is
  signaled, or becomes signaled, the function returns and the thread is allowed to
  continue execution.
  Note that successfully waiting on a dispatcher object can, depending on the object,
  modify the state of the underlying object. For example, the count of a semaphore
  is decreased by one before the method returns. See the individual synchronization
  classes and the Platform SDK for details.
Result:
  The result indicates success or failure and is of
  type TJclWaitResult. This type is shared
  between all WaitXxx functions and as such not all members of this enumeration can
  be returned from this method. Valid ones are wrError, wrAbandoned, wrTimeOut and
  wrSignaled. See TJclWaitResult for the details.
See also:
  WaitAlertable
  WaitFor
  WaitForMultipleObjects
  WaitAlertableForMultipleObjects
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.Attach
Summary:
  Attaches to an existing dispatcher object.
Description:
  The Attach constructor attaches to the existing dispatcher object specified by
  Handle. This is particularly useful when passing handles between a parent and
  child process using handle inheritance.
Parameters:
  Handle - Handle of the dispatcher object to attach to. This must be a handle to an event, mutex, semaphore, waitable timer or timer queue.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclDispatcherObject.Destroy
Summary:
  Disposes of the object instance.
Description:
  Destroy closes the handle to the dispatcher object and disposes of the object
  instance. After this call the object instance, as well as the dispatcher object
  wrapped by the class, are no longer valid. The state of any threads waiting on
  the object are often undefined and therefore you should never destroy an object
  with outstanding references. TJclDispatcherObject does not make any provisions
  for this, nor do any of the derived classes.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@LockedCompareExchange
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe compare and exchange.
Description:
  LockedCompareExchange compares Comp with Target. If they are equal the value of
  Exch is moved into Target, otherwise Target retains its value. All this is
  performed in a locked, thread-safe manner. The LockedXxx functions allow for a
  simple and efficient way for applications to synchronize access to and manipulate
  integer variables which are shared by multiple threads.
Parameters:
  Target - The target variable to compare Value and which conditionally receives the value of Exch.
  Exch - The value which is moved into Target if Comp and Target are equal.
  Comp - The comperand which Target is compared against.
Result:
  The value of Target on procedure entry. Depending on the comparison, Target may
  have been updated or have retained its value.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedExchangeSub
  LockedExchange
  LockedExchangeInc
  LockedExchangeDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedExchangeAdd
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe addition.
Description:
  LockedExchangeAdd implements threadsafe addition for integers. The function adds
  Value to Target and returns the previous value of Target. The LockedXxx functions
  allow for a simple and efficient way for applications to synchronize access to
  and manipulate integer variables which are shared by multiple threads.
Parameters:
  Target - The target variable to add Value to.
  Value - The value to add to Target
Result:
  The value of Target before the addition.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedExchangeSub
  LockedExchange
  LockedExchangeInc
  LockedExchangeDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedAdd
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe addition.
Description:
  LockedAdd implements threadsafe addition for integers. The function adds Value
  to Target and returns the new value of Target. The LockedXxx functions allow for
  a simple and efficient way for applications to synchronize access to and
  manipulate integer variables which are shared by multiple threads.
Parameters:
  Target - The target variable to add Value to.
  Value - The value to add to Target
Result:
  The resulting value of Target after the addition. Note that the actual value of
  the variable may have already changed.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedSub
  LockedExchange
  LockedInc
  LockedDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedExchangeSub
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe subtraction.
Description:
  LockedExchangeSub implements threadsafe subtraction for integers. The function
  subtracts Value from Target and returns the old value of Target. The LockedXxx
  functions allow for a simple and efficient way for applications to synchronize
  access to and manipulate integer variables which are shared by multiple threads.
Parameters:
  Target - The Target variable to manipulate.
  Value - The value to subtract from Target.
Result:
  The value of Target before the subtraction.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedExchangeAdd
  LockedExchange
  LockedExchangeInc
  LockedExchangeDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedSub
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe subtraction.
Description:
  LockedSub implements threadsafe subtraction for integers. The function subtracts
  Value from Target and returns the new value of Target. The LockedXxx functions
  allow for a simple and efficient way for applications to synchronize access to,
  and manipulate integer variables which are shared by multiple threads.
Parameters:
  Target - The Target variable to manipulate.
  Value - The value to subtract from Target.
Result:
  The resulting value of Target after the subtraction. Note that the actual value
  of the variable may have already changed!
Notes:
  The Win32 API provides similar functions. Lookup InterlockedXxx in the Platform SDK.
See also:
  LockedAdd
  LockedExchange
  LockedInc
  LockedDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedExchange
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe exchange.
Description:
  LockedExchange implements a thread safe exchange of two integer values. The function
  exchanges the values of Target and Value and returns the previous value of
  Target. The LockedXxx functions allow for a simple and efficient way for applications
  to synchronize access to and manipulate integer variables which are shared by
  multiple threads.
Parameters:
  Target - The Target variable.
  Value - The value to move into Target.
Result:
  The value of Target before the exchange.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedAdd
  LockedSub
  LockedInc
  LockedDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedExchangeInc
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe increment.
Description:
  LockedExchangeInc increments the specified Integer in an atomic, thread-safe manner.
  The LockedXxx functions allow for a simple and efficient way for applications to
  synchronize access to and manipulate integer variables which are shared by
  multiple threads.
Parameters:
  Target - The variable to increment.
Result:
  The value of Target before the increment.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedExchangeAdd
  LockedExchangeSub
  LockedExchange
  LockedExchangeDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedInc
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe increment.
Description:
  LockedInc increments the specified Integer in an atomic, thread-safe manner. The
  LockedXxx functions allow for a simple and efficient way for applications to
  synchronize access to and manipulate integer variables which are shared by
  multiple threads.
Parameters:
  Target - The variable to increment.
Result:
  The resulting value of Target after the increment. Note that the actual value of the
  variable may have already changed!
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedAdd
  LockedSub
  LockedExchange
  LockedDec
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedExchangeDec
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe decrement.
Description:
  LockedExchangeDec decrements the specified Integer in an atomic, thread-safe manner.
  The LockedXxx functions allow for a simple and efficient way for applications to
  synchronize access to and manipulate integer variables which are shared by
  multiple threads.
Parameters:
  Target - The variable to decrement.
Result:
  The value of Target before being decremented.
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedExchangeAdd
  LockedExchangeSub
  LockedExchange
  LockedInc
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@LockedDec
<GROUP LibrariesProcessesandThreads.Synchronization.Lockedintegermanipulation>
Summary:
  Thread safe decrement.
Description:
  LockedDec decrements the specified Integer in an atomic, thread-safe manner. The
  LockedXxx functions allow for a simple and efficient way for applications to
  synchronize access to and manipulate integer variables which are shared by
  multiple threads.
Parameters:
  Target - The variable to decrement.
Result:
  The value of Target after being decremented. Note that the actual value of the
  variable may have already changed!
Notes:
  The Win32 API provides similar functions. Look up InterlockedXxx in the Platform SDK.
See also:
  LockedAdd
  LockedSub
  LockedExchange
  LockedInc
Donator:
  Azret Botash
--------------------------------------------------------------------------------
@@TJclMeteredSection
<GROUP LibrariesProcessesandThreads.Synchronization.TJclMeteredSection>
Summary:
  Provides a fast alternative to the semaphore kernel object.
Description:
  TJclMeteredSection is basically nothing more than a semaphore kernel object except
  that it is much faster. Its speed comes from the fact that unless the calling
  thread has to enter a wait state, all code is executed in user mode. This in
  opposition to a semaphore which always requires a transition to kernel mode.
  This class is (almost) a straight port from the metered section object as presented
  in the article "A Quick and Versatile Synchronization Object", Dan Chou which is
  available from the MSDN Library (Technical Articles\Windows Platform\MultiThreading).
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMeteredSection.Enter
Summary:
  Enters the metered section.
Description:
  The Enter method decreases the count of the metered section object thereby granting
  access to the protected resource to a single thread. The method does not return
  until either access was granted, the specified timeout elapses or an error
  occurs.
Parameters:
  TimeOut - Specifies the time-out interval, in milliseconds. The function returns if the interval elapses, even if the metered section does not have an open slot. If Milliseconds is zero, the function tests the metered section's state a and returns immediately. If Milliseconds is INFINITE, the function's time-out interval never elapses.
Result:
  If access was granted the result is wrSignaled, if the specified TimeOut elapsed
  the result is wrTimeOut and if an error occured the result is wrError. Although
  TJclWaitResult includes other values, these should never be encountered as the
  function result.
Notes:
  The EnterMeteredSection function checks for an available slot in the metered section. If the metered section does not have an available slot, the calling thread enters an efficient wait state. The thread consumes very little processor time while waiting for a slot to become free.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMeteredSection.Leave
Summary:
  Increases the MeteredSection's count.
Description:
  The LeaveMeteredSection function increases the number of available slots of a metered
  section by a specified amount but never increases past the maximum count as specified
  during construction. As a result of incrementing the count one or more waiting threads
  may be released from their wait state. Note that incrementing the count is not thread
  bound. That is, all threads may call Leave even though they never called Enter.
Parameters:
  ReleaseCount - Specifies the number of the metered section's slots to release. The value must be greater than zero. If the specified amount would cause the metered section's count to exceed the maximum number of available slots specified during creation of the metered section, the number of available slots is not changed and the function returns False.
  PrevCount - 32-bit Longint which receives the previous metered section open slot count.
Result:
  If the function succeeds the result is True, otherwise the result is False.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMeteredSection.Create
Summary:
  Creates an instance of a TJclMeteredSection object.
Description:
  Creates a named or unnamed instance of a TJclMeteredSection object.
Parameters:
  InitialCount - Specifies an initial count of open slots for the metered section. This value must be greater than or equal to zero and less than or equal to MaxCount. A slot is available when the count is greater than zero and none is available when it is zero. The count is decreased by one whenever the EnterMeteredSection function releases a thread that was waiting for the metered section. The count is increased by a specified amount by calling the LeaveMeteredSection function.
  MaxCount - Specifies the maximum number of available slots for the metered section. This value must be greater than zero.
  Name - String specifying the name of the metered section. The name is limited to MAX_METSECT_NAMELEN characters, and can contain any character except the backslash path-separator character (\). Name comparison is case sensitive. If Name matches the name of an existing named metered section, the InitialCount and MaxCount parameters are ignored because they have already been set by the process that originally created the metered section. If Name is empty, the metered section is created without a name.
Donator:
  Marcel van Brakel
--------------------------------------------------------------------------------
@@TJclMeteredSection.Open
Summary:
  The Open constructor attempts to open the existing named MeteredSection specified with Name.
Description:
  Opens an existing, named MeteredSection. If the MeteredSection object does not exist, or the calling
  thread does not have sufficient access to open the MeteredSection object, the constructor
  fails by raising an EJclMeteredSectionError exception.
Parameters:
  Name - Name of the MeteredSection object to open.
Donator:
  Marcel van Brakel