Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

OpenDarwin 7.2.1 - man page for tcl_mutexunlock (opendarwin section 3)

Threads(3)			      Tcl Library Procedures			       Threads(3)


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

       #include <tcl.h>


       Tcl_ConditionWait(condPtr, mutexPtr, timePtr)


       Void *
       Tcl_GetThreadData(keyPtr, size)




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

       Tcl_JoinThread(id, result)

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

       Tcl_Condition	   *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_Get-

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

       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.

       Beginning  with the 8.1 release, the Tcl core is thread safe, which allows you to incorpo-
       rate 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 given to the new thread and modify the behaviour through the supplied  flags. |
       The  value  TCL_THREAD_STACK_DEFAULT  for the stackSize indicates that the default size as |
       specified by the operating system is to be used for the new thread. As for the flags, cur- |
       rently  are  only the values TCL_THREAD_NOFLAGS and TCL_THREAD_JOINABLE defined. The first |
       of them invokes the default behaviour with no specialties. Using the  second  value  marks |
       the  new  thread  as joinable. This means that another thread can wait for the such marked |
       thread to exit and join it.								  |

       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.

       Tcl  does provide Tcl_ExitThread and Tcl_FinalizeThread for terminating threads and invok-
       ing 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 must have been marked as joinable through usage of the  TCL_THREAD_JOINABLE- |
       flag during its creation via Tcl_CreateThread.						  |

       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 possi- |
       ble,   the  system  will  retain  the  necessary  information  until  after  the  call  to |
       Tcl_JoinThread.	This means that not calling Tcl_JoinThread for	a  joinable  thread  will |
       cause a memory leak.

       Tcl  provides Tcl_ThreadQueueEvent and Tcl_ThreadAlert for handling event queueing in mul-
       tithreaded applications.  See the Notifier manual page for more information on these  pro-

       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 of a Tcl	"Thread"  package  imple-
       menting thread creation and management commands at the script level.

       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.  The result of locking a mutex twice from	the  same |
       thread  is undefined.  On some platforms it will result in a deadlock.  The Tcl_MutexLock,
       Tcl_MutexUnlock and Tcl_MutexFinalize procedures are defined as empty macros if	not  com-
       piling with 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.	  |

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

       The Tcl_GetThreadData call returns a pointer to a block of thread-private data.	Its argu-
       ment  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.

       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 handlers (if living that long) or explicitly by |
       calls to Tcl_MutexFinalize or Tcl_ConditionFinalize.  Thread local  storage  is	reclaimed
       during Tcl_FinalizeThread.

       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.

       Tcl_GetCurrentThread,  Tcl_ThreadQueueEvent,  Tcl_ThreadAlert,  Tcl_ExitThread, Tcl_Final-
       izeThread, Tcl_CreateThreadExitHandler, Tcl_DeleteThreadExitHandler

       thread, mutex, condition variable, thread local storage

Tcl					       8.1				       Threads(3)

All times are GMT -4. The time now is 11:49 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password