|  | 
 ThreadsAllegro 4.9 includes a simple cross-platform threading interface. It is a thin layer on top of two threading APIs: Windows threads and POSIX Threads (pthreads). Enforcing a consistent semantics on all platforms would be difficult at best, hence the behaviour of the following functions will differ subtly on different platforms (more so than usual). Your best bet is to be aware of this and code to the intersection of the semantics and avoid edge cases. ALLEGRO_THREADAn opaque structure representing a thread. ALLEGRO_MUTEXAn opaque structure representing a mutex. ALLEGRO_CONDAn opaque structure representing a condition variable. al_create_threadSpawn a new thread which begins executing  Return value: Returns true if the thread was created, false if there was an error. See also: al_start_thread, al_join_thread. al_start_threadWhen a thread is created, it is initially in a suspended state. Calling  Starting a thread which has already been started does nothing. See also: al_create_thread. al_join_threadWait for the thread to finish executing. This implicitly calls  If  See also: al_set_thread_should_stop, al_get_thread_should_stop, al_destroy_thread. al_set_thread_should_stopSet the flag to indicate  See also: al_join_thread, al_get_thread_should_stop. al_get_thread_should_stopCheck if another thread is waiting for  Return value: Return true if another thread has called  See also: al_join_thread, al_set_thread_should_stop. Note: We don't support forceful killing of threads. al_destroy_threadFree the resources used by a thread. Implicitly performs  Does nothing if  See also: al_join_thread. al_create_mutexCreate the mutex object (a mutual exclusion device). The mutex may or may not support "recursive" locking. Return value: Returns the mutex on success or  See also: al_create_mutex_recursive. al_create_mutex_recursiveCreate the mutex object (a mutual exclusion device), with support for "recursive" locking. That is, the mutex will count the number of times it has been locked by the same thread. If the caller tries to acquire a lock on the mutex when it already holds the lock then the count is incremented. The mutex is only unlocked when the thread releases the lock on the mutex an equal number of times, i.e. the count drops down to zero. See also: al_create_mutex. al_lock_mutexAcquire the lock on  If the mutex is already locked by the calling thread, then the behaviour depends on whether the mutex was created with  See also: al_unlock_mutex. We don't yet have al_mutex_trylock. al_unlock_mutexRelease the lock on  If the calling thread doesn't hold the lock, or if the mutex is not locked, undefined behaviour results. See also: al_lock_mutex. al_destroy_mutexFree the resources used by the mutex. The mutex should be unlocked. Destroying a locked mutex results in undefined behaviour. Does nothing if  al_create_condCreate a condition variable. Return value: Returns the condition value on success or  al_destroy_condDestroy a condition variable. Destroying a condition variable which has threads block on it results in undefined behaviour. Does nothing if  al_wait_condOn entering this function,  Example of proper use: The mutex should be locked before checking the condition, and should be rechecked  See also: al_wait_cond_timed, al_broadcast_cond, al_signal_cond. al_wait_cond_timedLike  Return value: Returns zero on success, non-zero if the call timed out. Fix up the return value. pthread_cond_timedwait returns ETIMEDOUT but can return other errors. Do we need to return other errors? al_broadcast_condUnblock all threads currently waiting on a condition variable. That is, broadcast that some condition which those threads were waiting for has become true. See also: al_signal_cond. Note: The pthreads spec says to lock the mutex associated with  al_signal_condUnblock at least one thread waiting on a condition variable. Generally you should use  See also: al_broadcast_cond. | 
Last updated: 2009-07-05 05:34:34 UTC