Wt  3.2.1
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Groups Pages
Public Member Functions
Wt::SyncLock< Lock > Class Template Reference

An dead-lock avoidance adaptor for a Boost mutex lock. More...

#include <Wt/SyncLock>

List of all members.

Public Member Functions

template<class Mutex >
 SyncLock (Mutex &mutex)
 Creates a RIIA lock.
template<class Mutex >
 SyncLock (Mutex &mutex, boost::defer_lock_t)
 Creates a RIIA lock, but defers taking the lock.
void lock ()
 Tries to acquire the lock, blocking while waiting.

Detailed Description

template<class Lock>
class Wt::SyncLock< Lock >

An dead-lock avoidance adaptor for a Boost mutex lock.

A SyncLock adapts a Boost mutex lock (such as boost::mutex::scoped_lock), and provides the same API as the original lock (it derives from it).

Just as can be expected by a lock, a call to lock() will block until the thread has exclusive access to the mutex.

While waiting to acquire the lock, however, the current Wt::WApplication lock, may be temporarily released in favor of another helper thread trying to acquire the application lock. Thus, you need to be aware that when the lock is taken, some other thread may have modified the current application state.

A sync lock is useful in the context of a deployment where multiple (or all) WApplication instances are running in a single process and communicating with each other (such as the built-in httpd). Then, this lock adaptor helps in avoiding a dead-lock situation when applications wants to access a shared resource protected by a mutex, which communicates to other applications while taking their update lock. In that case, it is likely that you will also want to iterate over all "registered" applications while holding the global mutex, and this creates a natural dead-lock scenario because you have two mutexes (global mutex, application mutex) which are sequentially aquired in a different order:

The altered behaviour of a call by application A to lock() is that this application A's state may be updated by another thread (e.g. serving application B), which tries to take A's update lock.

The following conventional locking code:

boost::recursive_mutex::scoped_lock lock(mutex_);

is updated to a sync lock, by doing:


Constructor & Destructor Documentation

template<class Lock>
template<class Mutex >
Wt::SyncLock< Lock >::SyncLock ( Mutex &  mutex)

Creates a RIIA lock.

Initializes and acquires exclusive access to the mutex.

template<class Lock>
template<class Mutex >
Wt::SyncLock< Lock >::SyncLock ( Mutex &  mutex,
boost::defer_lock_t   
)

Creates a RIIA lock, but defers taking the lock.

Initialize the lock but defers taking the lock.

See also:
lock()

Member Function Documentation

template<class Lock>
void Wt::SyncLock< Lock >::lock ( )

Tries to acquire the lock, blocking while waiting.

While an application A is waiting for the lock, its state may be updated by another application: another application B can succesfully take A's update lock.

Therefore you need to be prepared to deal with application state changes while waiting for the lock.


Generated on Sun May 27 2012 for the C++ Web Toolkit (Wt) by doxygen 1.8.1