Provided by: tcl8.4-doc_8.4.20-7_all bug

NAME

       Tcl_ConditionNotify,    Tcl_ConditionWait,   Tcl_ConditionFinalize,   Tcl_GetThreadData,   Tcl_MutexLock,
       Tcl_MutexUnlock, Tcl_MutexFinalize, Tcl_CreateThread, Tcl_JoinThread - Tcl thread support.

SYNOPSIS

       #include <tcl.h>

       void
       Tcl_ConditionNotify(condPtr)

       void
       Tcl_ConditionWait(condPtr, mutexPtr, timePtr)

       void
       Tcl_ConditionFinalize(condPtr)

       Void *
       Tcl_GetThreadData(keyPtr, size)

       void
       Tcl_MutexLock(mutexPtr)

       void
       Tcl_MutexUnlock(mutexPtr)

       void
       Tcl_MutexFinalize(mutexPtr)

       int
       Tcl_CreateThread(idPtr, threadProc, clientData, stackSize, flags)

       int
       Tcl_JoinThread(id, result)

ARGUMENTS

       Tcl_Condition       *condPtr  (in)      A condition variable, which must be associated with a mutex lock.

       Tcl_Mutex           *mutexPtr (in)      A mutex lock.

       Tcl_Time            *timePtr  (in)      A time limit on the condition wait.  NULL to wait forever.   Note
                                               that a polling value of 0 seconds doesn't make much sense.

       Tcl_ThreadDataKey   *keyPtr   (in)      This  identifies a block of thread local storage.  The key should
                                               be  static  and  process-wide,  yet  each  thread  will  end   up
                                               associating a different block of storage with this key.

       int                 *size     (in)      The  size of the thread local storage block.  This amount of data
                                               is allocated and initialized to zero the first time  each  thread
                                               calls Tcl_GetThreadData.

       Tcl_ThreadId        *idPtr    (out)     The  referred  storage  will  contain the id of the newly created
                                               thread as returned by the operating system.

       Tcl_ThreadId        id        (in)      Id of the thread waited upon.

       Tcl_ThreadCreateProc          threadProc(in)
                                               This procedure will act  as  the  main()  of  the  newly  created
                                               thread. The specified clientData will be its sole argument.

       ClientData          clientData(in)      Arbitrary information. Passed as sole argument to the threadProc.

       int                 stackSize (in)      The size of the stack given to the new thread.

       int                 flags     (in)      Bitmask  containing flags allowing the caller to modify behaviour
                                               of the new thread.

       int                 *result   (out)     The referred storage is used to place the exit code of the thread
                                               waited upon into it.
_________________________________________________________________

INTRODUCTION

       Beginning with the 8.1 release, the Tcl core is thread safe, which allows you  to  incorporate  Tcl  into
       multithreaded  applications  without customizing the Tcl core.  To enable Tcl multithreading support, you
       must include the --enable-threads option to configure when you configure and compile your Tcl core.

       An important constraint of the Tcl threads implementation is that only the  thread  that  created  a  Tcl
       interpreter  can  use  that  interpreter.   In  other words, multiple threads can not access the same Tcl
       interpreter.  (However, as was the case in previous releases, a single thread can safely create  and  use
       multiple interpreters.)

       Tcl  does  provide  Tcl_CreateThread for creating threads. The caller can determine the size of the stack 2
       given  to  the  new  thread  and  modify  the  behaviour  through   the   supplied   flags.   The   value 2
       TCL_THREAD_STACK_DEFAULT  for the stackSize indicates that the default size as specified by the operating 2
       system  is  to  be  used  for  the  new  thread.  As  for  the  flags,  currently  are  only  the  values 2
       TCL_THREAD_NOFLAGS  and TCL_THREAD_JOINABLE defined. The first of them invokes the default behaviour with 2
       no specialties. Using the second value marks the new thread as joinable. This means that  another  thread 2
       can wait for the such marked thread to exit and join it.                                                  2

       Restrictions:  On some unix systems the pthread-library does not contain the functionality to specify the 2
       stacksize of a thread. The specified value for the stacksize is ignored on these  systems.  Both  Windows 2
       and  Macintosh  currently  do not support joinable threads. This flag value is therefore ignored on these 2
       platforms.

       Tcl does provide Tcl_ExitThread and Tcl_FinalizeThread for terminating threads and invoking optional per-
       thread exit handlers.  See the Tcl_Exit page for more information on these procedures.

       The Tcl_JoinThread function is provided to allow threads to wait upon the exit of another  thread,  which 2
       must  have  been marked as joinable through usage of the TCL_THREAD_JOINABLE-flag during its creation via 2
       Tcl_CreateThread.                                                                                         2

       Trying to wait for the exit of a non-joinable thread or a thread which is already waited upon will result 2
       in an error. Waiting for a joinable thread which already exited is possible, the system will  retain  the 2
       necessary information until after the call to Tcl_JoinThread.  This means that not calling Tcl_JoinThread 2
       for a joinable thread will cause a memory leak.

       Tcl  provides  Tcl_ThreadQueueEvent  and  Tcl_ThreadAlert  for  handling  event queueing in multithreaded
       applications.  See the Notifier manual page for more information on these procedures.

       In this release, the Tcl language itself provides no support  for  creating  multithreaded  scripts  (for
       example,  scripts  that  could  spawn  a  Tcl interpreter in a separate thread).  If you need to add this
       feature at this time, see the tclThreadTest.c file in the Tcl source  distribution  for  an  experimental
       implementation  or  use the Tcl "Threading Extension" package implementing thread creation and management
       commands at the script level.

DESCRIPTION

       A mutex is a lock that is used to serialize all threads through a piece of code by calling  Tcl_MutexLock
       and  Tcl_MutexUnlock.   If  one  thread  holds a mutex, any other thread calling Tcl_MutexLock will block
       until Tcl_MutexUnlock is called.  A mutex can be destroyed after its use  by  calling  Tcl_MutexFinalize. 2
       The  result of locking a mutex twice from the same thread is undefined.  On some platforms it will result 2
       in a deadlock.  The Tcl_MutexLock, Tcl_MutexUnlock and Tcl_MutexFinalize procedures are defined as  empty
       macros  if  not  compiling  with threads enabled.  For declaration of mutexes the TCL_DECLARE_MUTEX macro
       should be used.  This macro assures correct mutex handling even when the core is compiled without threads
       enabled.

       A condition variable is used as a signaling mechanism: a thread can lock a  mutex  and  then  wait  on  a
       condition  variable  with  Tcl_ConditionWait.   This  atomically  releases  the mutex lock and blocks the
       waiting thread until another thread calls Tcl_ConditionNotify.  The caller of Tcl_ConditionNotify  should
       have  the associated mutex held by previously calling Tcl_MutexLock, but this is not enforced.  Notifying
       the condition variable unblocks all threads waiting on the condition variable, but they  do  not  proceed
       until  the mutex is released with Tcl_MutexUnlock.  The implementation of Tcl_ConditionWait automatically
       locks the mutex before returning.

       The  caller  of  Tcl_ConditionWait  should  be   prepared   for   spurious   notifications   by   calling
       Tcl_ConditionWait within a while loop that tests some invariant.

       A condition variable can be destroyed after its use by calling Tcl_ConditionFinalize.                     2

       The  Tcl_ConditionNotify,  Tcl_ConditionWait  and  Tcl_ConditionFinalize  procedures are defined as empty 2
       macros if not compiling with threads enabled.

       The Tcl_GetThreadData call returns a pointer to a block of thread-private data.  Its argument  is  a  key
       that  is  shared  by  all  threads  and  a  size  for the block of storage.  The storage is automatically
       allocated and initialized to all zeros  the  first  time  each  thread  asks  for  it.   The  storage  is
       automatically deallocated by Tcl_FinalizeThread.

INITIALIZATION

       All of these synchronization objects are self initializing.  They are implemented as opaque pointers that
       should be NULL upon first use.  The mutexes and condition variables are either cleaned up by process exit 2
       handlers  (if  living  that  long)  or explicitly by calls to Tcl_MutexFinalize or Tcl_ConditionFinalize.
       Thread local storage is reclaimed during Tcl_FinalizeThread.

CREATING THREADS

       The API to create threads is not finalized at this time.  There are private facilities to create  threads
       that  contain  a  new  Tcl interpreter, and to send scripts among threads.  Dive into tclThreadTest.c and
       tclThread.c for examples.

SEE ALSO

       Tcl_GetCurrentThread,   Tcl_ThreadQueueEvent,   Tcl_ThreadAlert,   Tcl_ExitThread,    Tcl_FinalizeThread,
       Tcl_CreateThreadExitHandler, Tcl_DeleteThreadExitHandler

KEYWORDS

       thread, mutex, condition variable, thread local storage

Tcl                                                    8.1                                         Threads(3tcl)