StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>As the name implies, the Mutex is <code>recursive</code> but the Lock is not.</p> <p>That said, you have here a design problem. The locking operations would be better off not being accessible from the outside.</p> <pre><code>class SynchronizedInt { public: explicit SynchronizedInt(int i = 0): mData(i) {} int get() const { lock_type lock(mMutex); toolbox::ignore_unused_variable_warning(lock); return mData; } void set(int i) { lock_type lock(mMutex); toolbox::ignore_unused_variable_warning(lock); mData = i; } private: typedef boost::recursive_mutex mutex_type; typedef boost::unique_lock<mutex_type> lock_type; int mData; mutable mutex_type mMutex; }; </code></pre> <p>The main point of the <code>recursive_mutex</code> is to allow chain locking in a given thread which may occur if you have complex operations that call each others in some case.</p> <p>For example, let's add tweak get:</p> <pre><code>int SynchronizedInt::UnitializedValue = -1; int SynchronizedInt::get() const { lock_type lock(mMutex); if (mData == UnitializedValue) this->fetchFromCache(); return mData; } void SynchronizedInt::fetchFromCache() { this->set(this->fetchFromCacheImpl()); } </code></pre> <p>Where is the problem here ?</p> <ul> <li><code>get</code> acquires the lock on <code>mMutex</code></li> <li>it calls <code>fetchFromCache</code> which calls <code>set</code></li> <li><code>set</code> attempts to acquire the lock...</li> </ul> <p>If we did not have a <code>recursive_mutex</code>, this would fail.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload