[25] | 1 | '\" |
---|
| 2 | '\" Copyright (c) 1999 Scriptics Corporation |
---|
| 3 | '\" Copyright (c) 1998 Sun Microsystems, Inc. |
---|
| 4 | '\" |
---|
| 5 | '\" See the file "license.terms" for information on usage and redistribution |
---|
| 6 | '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES. |
---|
| 7 | '\" |
---|
| 8 | '\" RCS: @(#) $Id: Thread.3,v 1.28 2007/12/13 15:22:32 dgp Exp $ |
---|
| 9 | '\" |
---|
| 10 | .so man.macros |
---|
| 11 | .TH Threads 3 "8.1" Tcl "Tcl Library Procedures" |
---|
| 12 | .BS |
---|
| 13 | .SH NAME |
---|
| 14 | Tcl_ConditionNotify, Tcl_ConditionWait, Tcl_ConditionFinalize, Tcl_GetThreadData, Tcl_MutexLock, Tcl_MutexUnlock, Tcl_MutexFinalize, Tcl_CreateThread, Tcl_JoinThread \- Tcl thread support |
---|
| 15 | .SH SYNOPSIS |
---|
| 16 | .nf |
---|
| 17 | \fB#include <tcl.h>\fR |
---|
| 18 | .sp |
---|
| 19 | void |
---|
| 20 | \fBTcl_ConditionNotify\fR(\fIcondPtr\fR) |
---|
| 21 | .sp |
---|
| 22 | void |
---|
| 23 | \fBTcl_ConditionWait\fR(\fIcondPtr, mutexPtr, timePtr\fR) |
---|
| 24 | .sp |
---|
| 25 | void |
---|
| 26 | \fBTcl_ConditionFinalize\fR(\fIcondPtr\fR) |
---|
| 27 | .sp |
---|
| 28 | Void * |
---|
| 29 | \fBTcl_GetThreadData\fR(\fIkeyPtr, size\fR) |
---|
| 30 | .sp |
---|
| 31 | void |
---|
| 32 | \fBTcl_MutexLock\fR(\fImutexPtr\fR) |
---|
| 33 | .sp |
---|
| 34 | void |
---|
| 35 | \fBTcl_MutexUnlock\fR(\fImutexPtr\fR) |
---|
| 36 | .sp |
---|
| 37 | void |
---|
| 38 | \fBTcl_MutexFinalize\fR(\fImutexPtr\fR) |
---|
| 39 | .sp |
---|
| 40 | int |
---|
| 41 | \fBTcl_CreateThread\fR(\fIidPtr, threadProc, clientData, stackSize, flags\fR) |
---|
| 42 | .sp |
---|
| 43 | int |
---|
| 44 | \fBTcl_JoinThread\fR(\fIid, result\fR) |
---|
| 45 | .SH ARGUMENTS |
---|
| 46 | .AS Tcl_CreateThreadProc threadProc out |
---|
| 47 | .AP Tcl_Condition *condPtr in |
---|
| 48 | A condition variable, which must be associated with a mutex lock. |
---|
| 49 | .AP Tcl_Mutex *mutexPtr in |
---|
| 50 | A mutex lock. |
---|
| 51 | .AP Tcl_Time *timePtr in |
---|
| 52 | A time limit on the condition wait. NULL to wait forever. |
---|
| 53 | Note that a polling value of 0 seconds does not make much sense. |
---|
| 54 | .AP Tcl_ThreadDataKey *keyPtr in |
---|
| 55 | This identifies a block of thread local storage. The key should be |
---|
| 56 | static and process-wide, yet each thread will end up associating |
---|
| 57 | a different block of storage with this key. |
---|
| 58 | .AP int *size in |
---|
| 59 | The size of the thread local storage block. This amount of data |
---|
| 60 | is allocated and initialized to zero the first time each thread |
---|
| 61 | calls \fBTcl_GetThreadData\fR. |
---|
| 62 | .AP Tcl_ThreadId *idPtr out |
---|
| 63 | The referred storage will contain the id of the newly created thread as |
---|
| 64 | returned by the operating system. |
---|
| 65 | .AP Tcl_ThreadId id in |
---|
| 66 | Id of the thread waited upon. |
---|
| 67 | .AP Tcl_ThreadCreateProc threadProc in |
---|
| 68 | This procedure will act as the \fBmain()\fR of the newly created |
---|
| 69 | thread. The specified \fIclientData\fR will be its sole argument. |
---|
| 70 | .AP ClientData clientData in |
---|
| 71 | Arbitrary information. Passed as sole argument to the \fIthreadProc\fR. |
---|
| 72 | .AP int stackSize in |
---|
| 73 | The size of the stack given to the new thread. |
---|
| 74 | .AP int flags in |
---|
| 75 | Bitmask containing flags allowing the caller to modify behaviour of |
---|
| 76 | the new thread. |
---|
| 77 | .AP int *result out |
---|
| 78 | The referred storage is used to place the exit code of the thread |
---|
| 79 | waited upon into it. |
---|
| 80 | .BE |
---|
| 81 | .SH INTRODUCTION |
---|
| 82 | Beginning with the 8.1 release, the Tcl core is thread safe, which |
---|
| 83 | allows you to incorporate Tcl into multithreaded applications without |
---|
| 84 | customizing the Tcl core. To enable Tcl multithreading support, |
---|
| 85 | you must include the \fB\-\|\-enable-threads\fR option to \fBconfigure\fR |
---|
| 86 | when you configure and compile your Tcl core. |
---|
| 87 | .PP |
---|
| 88 | An important constraint of the Tcl threads implementation is that |
---|
| 89 | \fIonly the thread that created a Tcl interpreter can use that |
---|
| 90 | interpreter\fR. In other words, multiple threads can not access |
---|
| 91 | the same Tcl interpreter. (However, a single thread can safely create |
---|
| 92 | and use multiple interpreters.) |
---|
| 93 | .SH DESCRIPTION |
---|
| 94 | Tcl provides \fBTcl_CreateThread\fR for creating threads. The |
---|
| 95 | caller can determine the size of the stack given to the new thread and |
---|
| 96 | modify the behaviour through the supplied \fIflags\fR. The value |
---|
| 97 | \fBTCL_THREAD_STACK_DEFAULT\fR for the \fIstackSize\fR indicates that |
---|
| 98 | the default size as specified by the operating system is to be used |
---|
| 99 | for the new thread. As for the flags, currently only the values |
---|
| 100 | \fBTCL_THREAD_NOFLAGS\fR and \fBTCL_THREAD_JOINABLE\fR are defined. The |
---|
| 101 | first of them invokes the default behaviour with no |
---|
| 102 | specialties. Using the second value marks the new thread as |
---|
| 103 | \fIjoinable\fR. This means that another thread can wait for the such |
---|
| 104 | marked thread to exit and join it. |
---|
| 105 | .PP |
---|
| 106 | Restrictions: On some UNIX systems the pthread-library does not |
---|
| 107 | contain the functionality to specify the stack size of a thread. The |
---|
| 108 | specified value for the stack size is ignored on these systems. |
---|
| 109 | Windows currently does not support joinable threads. This |
---|
| 110 | flag value is therefore ignored on this platform. |
---|
| 111 | .PP |
---|
| 112 | Tcl provides the \fBTcl_ExitThread\fR and \fBTcl_FinalizeThread\fR functions |
---|
| 113 | for terminating threads and invoking optional per-thread exit |
---|
| 114 | handlers. See the \fBTcl_Exit\fR page for more information on these |
---|
| 115 | procedures. |
---|
| 116 | .PP |
---|
| 117 | The \fBTcl_JoinThread\fR function is provided to allow threads to wait |
---|
| 118 | upon the exit of another thread, which must have been marked as |
---|
| 119 | joinable through usage of the \fBTCL_THREAD_JOINABLE\fR-flag during |
---|
| 120 | its creation via \fBTcl_CreateThread\fR. |
---|
| 121 | .PP |
---|
| 122 | Trying to wait for the exit of a non-joinable thread or a thread which |
---|
| 123 | is already waited upon will result in an error. Waiting for a joinable |
---|
| 124 | thread which already exited is possible, the system will retain the |
---|
| 125 | necessary information until after the call to \fBTcl_JoinThread\fR. |
---|
| 126 | This means that not calling \fBTcl_JoinThread\fR for a joinable thread |
---|
| 127 | will cause a memory leak. |
---|
| 128 | .PP |
---|
| 129 | The \fBTcl_GetThreadData\fR call returns a pointer to a block of |
---|
| 130 | thread-private data. Its argument is a key that is shared by all threads |
---|
| 131 | and a size for the block of storage. The storage is automatically |
---|
| 132 | allocated and initialized to all zeros the first time each thread asks for it. |
---|
| 133 | The storage is automatically deallocated by \fBTcl_FinalizeThread\fR. |
---|
| 134 | .SS "SYNCHRONIZATION AND COMMUNICATION" |
---|
| 135 | Tcl provides \fBTcl_ThreadQueueEvent\fR and \fBTcl_ThreadAlert\fR |
---|
| 136 | for handling event queuing in multithreaded applications. See |
---|
| 137 | the \fBNotifier\fR manual page for more information on these procedures. |
---|
| 138 | .PP |
---|
| 139 | A mutex is a lock that is used to serialize all threads through a piece |
---|
| 140 | of code by calling \fBTcl_MutexLock\fR and \fBTcl_MutexUnlock\fR. |
---|
| 141 | If one thread holds a mutex, any other thread calling \fBTcl_MutexLock\fR will |
---|
| 142 | block until \fBTcl_MutexUnlock\fR is called. |
---|
| 143 | A mutex can be destroyed after its use by calling \fBTcl_MutexFinalize\fR. |
---|
| 144 | The result of locking a mutex twice from the same thread is undefined. |
---|
| 145 | On some platforms it will result in a deadlock. |
---|
| 146 | The \fBTcl_MutexLock\fR, \fBTcl_MutexUnlock\fR and \fBTcl_MutexFinalize\fR |
---|
| 147 | procedures are defined as empty macros if not compiling with threads enabled. |
---|
| 148 | For declaration of mutexes the \fBTCL_DECLARE_MUTEX\fR macro should be used. |
---|
| 149 | This macro assures correct mutex handling even when the core is compiled |
---|
| 150 | without threads enabled. |
---|
| 151 | .PP |
---|
| 152 | A condition variable is used as a signaling mechanism: |
---|
| 153 | a thread can lock a mutex and then wait on a condition variable |
---|
| 154 | with \fBTcl_ConditionWait\fR. This atomically releases the mutex lock |
---|
| 155 | and blocks the waiting thread until another thread calls |
---|
| 156 | \fBTcl_ConditionNotify\fR. The caller of \fBTcl_ConditionNotify\fR should |
---|
| 157 | have the associated mutex held by previously calling \fBTcl_MutexLock\fR, |
---|
| 158 | but this is not enforced. Notifying the |
---|
| 159 | condition variable unblocks all threads waiting on the condition variable, |
---|
| 160 | but they do not proceed until the mutex is released with \fBTcl_MutexUnlock\fR. |
---|
| 161 | The implementation of \fBTcl_ConditionWait\fR automatically locks |
---|
| 162 | the mutex before returning. |
---|
| 163 | .PP |
---|
| 164 | The caller of \fBTcl_ConditionWait\fR should be prepared for spurious |
---|
| 165 | notifications by calling \fBTcl_ConditionWait\fR within a while loop |
---|
| 166 | that tests some invariant. |
---|
| 167 | .PP |
---|
| 168 | A condition variable can be destroyed after its use by calling |
---|
| 169 | \fBTcl_ConditionFinalize\fR. |
---|
| 170 | .PP |
---|
| 171 | The \fBTcl_ConditionNotify\fR, \fBTcl_ConditionWait\fR and |
---|
| 172 | \fBTcl_ConditionFinalize\fR procedures are defined as empty macros if |
---|
| 173 | not compiling with threads enabled. |
---|
| 174 | .SS INITIALIZATION |
---|
| 175 | .PP |
---|
| 176 | All of these synchronization objects are self-initializing. |
---|
| 177 | They are implemented as opaque pointers that should be NULL |
---|
| 178 | upon first use. |
---|
| 179 | The mutexes and condition variables are |
---|
| 180 | either cleaned up by process exit handlers (if living that long) or |
---|
| 181 | explicitly by calls to \fBTcl_MutexFinalize\fR or |
---|
| 182 | \fBTcl_ConditionFinalize\fR. |
---|
| 183 | Thread local storage is reclaimed during \fBTcl_FinalizeThread\fR. |
---|
| 184 | .SH "SCRIPT-LEVEL ACCESS TO THREADS" |
---|
| 185 | .VS 8.5 |
---|
| 186 | Tcl provides no built-in commands for scripts to use to create, |
---|
| 187 | manage, or join threads, nor any script-level access to mutex or |
---|
| 188 | condition variables. It provides such facilities only via C |
---|
| 189 | interfaces, and leaves it up to packages to expose these matters to |
---|
| 190 | the script level. One such package is the \fBThread\fR package. |
---|
| 191 | .VE 8.5 |
---|
| 192 | .SH "SEE ALSO" |
---|
| 193 | Tcl_GetCurrentThread(3), Tcl_ThreadQueueEvent(3), Tcl_ThreadAlert(3), |
---|
| 194 | Tcl_ExitThread(3), Tcl_FinalizeThread(3), Tcl_CreateThreadExitHandler(3), |
---|
| 195 | Tcl_DeleteThreadExitHandler(3), Thread |
---|
| 196 | .SH KEYWORDS |
---|
| 197 | thread, mutex, condition variable, thread local storage |
---|