通讯编程

开发平台：
Visual C++

Thread.3：源码内容
							'"
'" Copyright (c) 1999 Scriptics Corporation
'" Copyright (c) 1998 Sun Microsystems, Inc.
'"
'" See the file "license.terms" for information on usage and redistribution
'" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
'" 
'" RCS: @(#) $Id: Thread.3,v 1.14.2.2 2004/11/25 15:48:52 vasiljevic Exp $
'" 
.so man.macros
.TH Threads 3 "8.1" Tcl "Tcl Library Procedures"
.BS
.SH NAME
Tcl_ConditionNotify, Tcl_ConditionWait, Tcl_ConditionFinalize, Tcl_GetThreadData, Tcl_MutexLock, Tcl_MutexUnlock, Tcl_MutexFinalize, Tcl_CreateThread, Tcl_JoinThread - Tcl thread support.
.SH SYNOPSIS
.nf
fB#include <tcl.h>fR
.sp
void
fBTcl_ConditionNotifyfR(fIcondPtrfR)
.sp
void
fBTcl_ConditionWaitfR(fIcondPtr, mutexPtr, timePtrfR)
.sp
void
fBTcl_ConditionFinalizefR(fIcondPtrfR)
.sp
Void *
fBTcl_GetThreadDatafR(fIkeyPtr, sizefR)
.sp
void
fBTcl_MutexLockfR(fImutexPtrfR)
.sp
void
fBTcl_MutexUnlockfR(fImutexPtrfR)
.sp
void
fBTcl_MutexFinalizefR(fImutexPtrfR)
.sp
int
fBTcl_CreateThreadfR(fIidPtr, threadProc, clientData, stackSize, flagsfR)
.sp
int
fBTcl_JoinThreadfR(fIid, resultfR)
.SH ARGUMENTS
.AS Tcl_ThreadDataKey *keyPtr
.AP Tcl_Condition *condPtr in
A condition variable, which must be associated with a mutex lock.
.AP Tcl_Mutex *mutexPtr in
A mutex lock.
.AP 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.
.AP 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.
.AP 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 fBTcl_GetThreadDatafR.
.AP Tcl_ThreadId *idPtr out
The referred storage will contain the id of the newly created thread as
returned by the operating system.
.AP Tcl_ThreadId id in
Id of the thread waited upon.
.AP Tcl_ThreadCreateProc threadProc in
This procedure will act as the fBmain()fR of the newly created
thread. The specified fIclientDatafR will be its sole argument.
.AP ClientData clientData in
Arbitrary information. Passed as sole argument to the fIthreadProcfR.
.AP int stackSize in
The size of the stack given to the new thread.
.AP int flags in
Bitmask containing flags allowing the caller to modify behaviour of
the new thread.
.AP int *result out
The referred storage is used to place the exit code of the thread
waited upon into it.
.BE
.SH 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 fB--enable-threadsfR option to fBconfigurefR
when you configure and compile your Tcl core.
.PP
An important constraint of the Tcl threads implementation is that
fIonly the thread that created a Tcl interpreter can use that
interpreterfR.  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.)
.PP
.VS 8.3.1
Tcl does provide fBTcl_CreateThreadfR for creating threads. The
caller can determine the size of the stack given to the new thread and
modify the behaviour through the supplied fIflagsfR. The value
fBTCL_THREAD_STACK_DEFAULTfR for the fIstackSizefR indicates that
the default size as specified by the operating system is to be used
for the new thread. As for the flags, currently are only the values
fBTCL_THREAD_NOFLAGSfR and fBTCL_THREAD_JOINABLEfR defined. The
first of them invokes the default behaviour with no
specialties. Using the second value marks the new thread as
fIjoinablefR. This means that another thread can wait for the such
marked thread to exit and join it.
.PP
Restrictions: On some unix systems the pthread-library does not
contain the functionality to specify the stacksize of a thread. The
specified value for the stacksize is ignored on these systems. Both
Windows and Macintosh currently do not support joinable threads. This
flag value is therefore ignored on these platforms.
.VE
.PP
Tcl does provide fBTcl_ExitThreadfR and fBTcl_FinalizeThreadfR
for terminating threads and invoking optional per-thread exit
handlers.  See the fBTcl_ExitfR page for more information on these
procedures.
.PP
.VS
The fBTcl_JoinThreadfR function is provided to allow threads to wait
upon the exit of another thread, which must have been marked as
joinable through usage of the fBTCL_THREAD_JOINABLEfR-flag during
its creation via fBTcl_CreateThreadfR.
.PP
Trying to wait for the exit of a non-joinable thread or a thread which
is already waited upon will result in an error. Waiting for a joinable
thread which already exited is possible, the system will retain the
necessary information until after the call to fBTcl_JoinThreadfR.
This means that not calling fBTcl_JoinThreadfR for a joinable thread
will cause a memory leak.
.VE
.PP
Tcl provides fBTcl_ThreadQueueEventfR and fBTcl_ThreadAlertfR
for handling event queueing in multithreaded applications.  See
the fBNotifierfR manual page for more information on these procedures.
.PP
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 fItclThreadTest.cfR
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.
.SH DESCRIPTION
A mutex is a lock that is used to serialize all threads through a piece
of code by calling fBTcl_MutexLockfR and fBTcl_MutexUnlockfR.
If one thread holds a mutex, any other thread calling fBTcl_MutexLockfR will
block until fBTcl_MutexUnlockfR is called.
.VS
A mutex can be destroyed after its use by calling fBTcl_MutexFinalizefR.
The result of locking a mutex twice from the same thread is undefined.
On some platforms it will result in a deadlock.
.VE
The fBTcl_MutexLockfR, fBTcl_MutexUnlockfR and fBTcl_MutexFinalizefR
procedures are defined as empty macros if not compiling with threads enabled.
For declaration of mutexes the fBTCL_DECLARE_MUTEXfR macro should be used.
This macro assures correct mutex handling even when the core is compiled
without threads enabled. 
.PP
A condition variable is used as a signaling mechanism:
a thread can lock a mutex and then wait on a condition variable
with fBTcl_ConditionWaitfR.  This atomically releases the mutex lock
and blocks the waiting thread until another thread calls
fBTcl_ConditionNotifyfR.  The caller of fBTcl_ConditionNotifyfR should
have the associated mutex held by previously calling fBTcl_MutexLockfR,
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 fBTcl_MutexUnlockfR.
The implementation of fBTcl_ConditionWaitfR automatically locks
the mutex before returning.
.PP
The caller of fBTcl_ConditionWaitfR should be prepared for spurious
notifications by calling fBTcl_ConditionWaitfR within a while loop
that tests some invariant.
.PP
.VS
A condition variable can be destroyed after its use by calling
fBTcl_ConditionFinalizefR.
.PP
The fBTcl_ConditionNotifyfR, fBTcl_ConditionWaitfR and
fBTcl_ConditionFinalizefR procedures are defined as empty macros if
not compiling with threads enabled.
.VE
.PP
The fBTcl_GetThreadDatafR 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 fBTcl_FinalizeThreadfR.
.SH INITIALIZATION
.PP
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
.VS
either cleaned up by process exit handlers (if living that long) or
explicitly by calls to fBTcl_MutexFinalizefR or
fBTcl_ConditionFinalizefR.
.VE
Thread local storage is reclaimed during fBTcl_FinalizeThreadfR.
.SH "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.
.SH "SEE ALSO"
Tcl_GetCurrentThread, Tcl_ThreadQueueEvent, Tcl_ThreadAlert,
Tcl_ExitThread, Tcl_FinalizeThread,
Tcl_CreateThreadExitHandler, Tcl_DeleteThreadExitHandler
.SH KEYWORDS
thread, mutex, condition variable, thread local storage

						