The POSIX Threading and Synchronous Wrappers are a simple set of C++ classes that act as wrappers for the
POSIX threading and synchronous API. The implementation contains wrappers for threading, mutexes and conditions.
The model for threading code is based around an inheritance pattern. The pattern dictates that code which will
be threaded should exist within a method called execute which itself exists within a class derived directly
from or derived from derivations of the PosixThread class. Synchronous mechanisms such as mutexes and conditions
can be invoked from any point of code as long as the invocations of their members abide by the standard interfaces
provided by the wrappers, i.e.: sequential double locking a mutex within the same thread is a big no-no.
The POSIX Threading and Synchronous Wrappers provide a simple precise, concise, predictable interface for
the draft 4+ version of the POSIX threading API.
A simple class that allows a sequence of code that is implemented or invoked from a derived "execute"
method to be threaded.
The methods that are currently being wrapped are: pthread_create, pthread_detach, pthread_join, pthread_equal,
pthread_setschedparam, pthread_getschedparam, sched_yield, pthread_cancel, pthread_exit.
A simple class that allows for the definition of critical sections of code via locking and unlocking mechanisms.
Sections of code can be locked out so that other threads can not have access to it until the current thread has
released the lock. Mutexes are the ultimate form of synchronization and hence may not be the "best" solution for
some applications.
The methods that are currently being wrapped are: pthread_mutex_init, pthread_mutex_destroy, pthread_mutex_lock,
pthread_mutex_unlock, pthread_mutex_trylock.
A simple variant of the mutex class, in this implementation the locking and unlocking ocurrs in the constructor and
destructor of the class itself. This means that one could in theory lock an entire piece of code spanning the scope
of the POSIXScopeMutex instance.
This is an extended version of the mutexing paradigm. Its a mutex which has a bias towards reader threads. In this class
the locks only lock-out threads which intend to write within the critical section and only let threads which intended
to have read access through. Once all the readers have been serviced the writer threads are then serviced. The main
disadvantage of this method is that writer threads are treated as second class citizens meaning that as soon as a reader
thread wants to enter the critical section all the writer threads are placed on the proverbial back-burner until the reader
has completed the critical section. The locking and priority policy of this class can be easily modified to suit the needs
of the application at hand. The main problem is that if the POSIX Read-Write Mutex is used to lock a blocking resource and
the resource itself is locked either via system fault or otherwise, the threads in the pending queues of the POSIX Read-Write
Mutex may not be able to adequaetly recover.
The methods that are currently being wrapped are:pthread_mutex_destroy, pthread_mutex_init, pthread_mutex_lock, pthread_mutex_unlock,
pthread_cond_broadcast, pthread_cond_destroy, pthread_cond_init, pthread_cond_signal, pthread_cond_wait, pthread_condattr_destroy,
pthread_condattr_init, pthread_condattr_t.
A simple class that allows for signaling between threads. The condition variable can be used to broadcast a wake-up signal to threads
which are in a wait state for its particular signal. The condition metaphore is the basis of many threaded producer consumer constructs.
The only issue with the condition variable is that if not used properly meaning in the situation where many threads are waiting on a
particular signal this may cause a "thundering herd" effect which may cripple an operating system that does not have either sufficient
processing resources or has been poorly designed. Thundering herd is when many threads and/or processes are woken up simultaneously and
all race to the CPU in order to obtain CPU time slices so as to be able to service their wake-up call.
The methods that are currently being wrapped are: pthread_condattr_t, pthread_condattr_init, pthread_cond_init, pthread_condattr_destroy,
pthread_cond_destroy, pthread_cond_wait, pthread_cond_timedwait, pthread_cond_signal, pthread_cond_broadcast.
The POSIX Threading and Synchronous wrappers available here are a great way to understand how the POSIX threading
API can be incorparated in an object oriented context such as C++. However for more advanced application
programming where threading may be a nesscaity, a user should attempt to work within a threading framework.
Some popular frameworks are BOOST
and ACE. Both
these frame-works provide all the nesaccary components in one source base for threading, networking and other
established software engineering patterns.
In some situations either due to project requirments and specifications or licensing issues of open source frameworks such as
BOOST and ACE may lead some programmers to develop their own frameworks for a particular project. Developing ones own framework
allows the project code base to have a flavour of its own, allowing development of the project to occur around the principles of
the developers rather than a larger decentralized group of developers.
Free use of the POSIX Threading and Synchronous Wrappers is permitted under the guidelines and in accordance with the most current
version of the "Common Public License."
Updates to POSIXMutex and POSIXCondition. During initialization of their attribute variables in certain conditions the attributes would be corrupted A simple memset to zero fixes the problem.
7th September 2004
Updated POSIXCondition so that multiple threads can efficiently wait on a specific condition. Signal as defined in the POSIX specifications will awaken at least one waiter, broadcast will awaken all waiters.
24th August 2004
Fixed bug relating to pthread_cond_timedwait within POSIXCondition - It turns out that the nano-second time should be less than a second.
Fixed bug relating to the initialisation of mutex variables, currently they are being initialised as PTHREAD_MUTEX_RECURSIVE
