ccording to the principles
(
Multi threaded design rules
) we
accept references to volatile objects. We aim to use the introduced here Guard
objects to simultaneously remove volatileness and gain proper ownership of the
mutex inside of the object. All Guard objects expect that the client class
exposes its mutex via a member function with the signature:
Mutex& mutex() const;
This means that the actual mutex data member should be defined mutable.
Constructors of the Guard objects throw the
ots::config::ThreadResourceError::type (=boost::thread_resource_error)
exception because the placed inside boost::thread-based locking operations
throw the boost::thread_resource_error exception.
|