Main Page | Class Hierarchy | Alphabetical List | Class List | File List | Class Members

Synchronizer Overview

The Synchronizer derived classes Condition, Event, Mutex, ReadWriteLock and Semaphore implement objects to use for synchronization purposes in multithreaded applictions. Which one is actually used depends completely on the requirements of a given application. In most cases a Mutex will do just fine to protect "critical sections" of code. In other cases a thread may have to wait until a Condition is signaled or an Event is set (e.g. worker-threads that are supposed to wake up only if and when there's something to do while sleeping the other time without using any processing time).

While the Synchronizer class defines an interface of three methods common to all derived classes, the latter implement that in their different ways. Right now there are five such classes:

Condition ...

... is a synchronization object which allows a thread to suspend execution, repeatedly, until the Condition is signaled (by calling its broadcast() or signal() methods).

Event ...

... is a synchronization object whose only purpose in life is to be either signaled or not signaled. While the Mutex and Semaphore objects change their respective state by way of (intended) side-effects of calling their wait...() methods, with an Event object its state is completely under programs control which can decide if and when to set(), reset() or pulse() it.

Mutex ...

... is a synchronization object used to allow multiple threads to seria lize their access to shared data in a mutual-exclusive way. The thread that got a successfull lock() becomes its owner and remains the owner until that same thread calls the unLock() method to release the mutex.

ReadWriteLock ...

... is a synchronization object (multiple readers, single writer) which allows many threads to have simultaneous read-only access to data while allowing only one thread to have write access at any given time. They are typically used to protect data that is read-only more frequently than it is changed.

Semaphore ...

... is a synchronization object that has an integral value and a set of blocked processes associated with it. When the value is zero, there is a (possibly empty) set of threads awaiting the objects availability; otherwise, the size of the set is equal to the absolute value of the semaphore value. The latter can be incremented (by calling the objects post() method) or decremented (by calling one of its waiting methods) and is done as an indivisible operation. When an objects value() is less than or equal to zero, any process that attempts to lock it again will block or be informed that it is not possible to perform the operation.

All classes use "lazy initialization" i.e. the respective system-level synchronization object is neither created nor initialized by the constructor. It is created/setup only if and when it's actually used the first time. That means creating a class instance won't use any additional system ressources (which might be limited) as long as none the waiting methods are called. – Note that the copy constructors are declared private to avoid unintended copies of a Synchronizer instance. – See the respective documentation of these classes for more information.

I've borrowed quite a bit of documentation (terms, phrases, concepts) from The Open Group Base Specifications Issue 6, IEEE Std 1003.1 which I consulted frequently during development. In case my classes do not conform to the expected behaviour of synchronizing objects as defined by POSIX® it's completely my fault (unless, of course, you've just found a bug in the underlaying pthread system library). In any case, please drop me a note so that I can look into the issue.

This classes use GNU/Linux system libraries and no attempt is made to resemble their functionality for e.g. WinDOS systems: This software is not intended to run on other plattforms than GNU/Linux. It is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.

ChangeLog

Author:
Matthias Watermann
See also:
dfg::Synchronizer, dfg::Condition, dfg::Event, dfg::Mutex, dfg::ReadWriteLock, dfg::Semaphore
Generated on 30 Jun 2004 for project  Sync+  with
Doxygen 1.3.7  corrected  by sed  and HTMLtidy   -x-