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 |
---|