sync.hpp File Reference

Object Monitor based synchronisation. More...

Go to the source code of this file.

Description

Object Monitor based synchronisation.

The actual locking, signalling and waiting is implemented by delegating to the a mutex and for waiting also to a condition variable as provided by the C++ standard library. The purpose of the Sync baseclass is to provide a clear and simple „everyday“ concurrency coordination based on the Object Monitor Pattern. This pattern describes a way of dealing with synchronisation known to play well with scoping, encapsulation and responsibility for a single purpose. For performance critical code, other solutions (e.g. Atomics) might be preferable.

Usage

A class becomes lockable by inheriting from lib::Sync with the appropriate parametrisation. This causes any instance to inherit a monitor member (object), maintaining a dedicated a mutex and (optionally) a condition variable for waiting. The actual synchronisation is achieved by placing a guard object as local (stack) variable into a given scope (typically a member function body). This guard object of class lib::Sync::Lock accesses the enclosing object's monitor and automatically manages the locking and unlocking; optionally it may also be used to perform a wait-on-condition — the call to Lock::wait(predicate) will first check the predicate, and if it does not yield true, the thread will be put to sleep. It must be awakened from another thread by invoking notify_one|all and will then re-check the condition predicate. The wait_for variant allows to set a timeout to limit the sleep state, which implies however that the call may possibly return false in case the condition predicate is not (yet) fulfilled.

Note

• It is important to select a suitable parametrisation of the monitor. This is done by specifying one of the defined policy classes.
• Be sure to pick the recursive mutex implementation when recursive calls of synchronised functions can't be avoided. (performance penalty)
• You can't use the Lock::wait and Lock::notify functions unless you pick a parametrisation including a condition variable.
• The "this" pointer is fed to the ctor of the Lock guard object. Thus you may use any object's monitor as appropriate, especially in cases when adding the monitor to a given class may cause size problems.
• There is a special variant of the Lock guard called ClassLock, which can be used to lock based on a type, not an instance.

See also

mutex.h

sync-locking-test.cpp

sync-waiting-test.cpp

usage example: receiving session coomands

usage example: subsystem start/shutdown

Definition in file sync.hpp.

#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/util.hpp"
#include <mutex>
#include <condition_variable>
#include <chrono>

Namespaces
namespace	lib
	Implementation namespace for support and library code.
namespace	lib::sync
	Helpers and building blocks for Monitor based synchronisation.

Typedefs
using	NonrecursiveLock_NoWait = std::mutex
using	RecursiveLock_NoWait = std::recursive_mutex
using	NonrecursiveLock_Waitable = Condition< std::mutex >
using	RecursiveLock_Waitable = Condition< std::recursive_mutex >

Classes
struct	Condition< MTX >
struct	NoLocking
class	Monitor< IMPL >
	Object Monitor for synchronisation and waiting. More...
class	Sync< CONF >
	Facility for monitor object based locking. More...
class	Sync< CONF >::Lock
	scoped guard to control the actual locking. More...