Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>In the <code>boost::shared_mutex</code> class (which implements the UpgradeLockable concept), a single thread should not attempt to acquire both a shared and an upgradeable (or unique) lock. At any time, the UpgradeLockable can have N shared locks held (via <code>lock_shared</code>), and 1 upgradeable lock (via <code>lock_upgrade</code>). The upgradeable lock can request that it become a unique lock, which blocks until it can become the exclusive holder, which requires all shared locks be released. It is impossible to convert from a shared lock to a unique lock, or a shared lock to an upgradeable lock without releasing the shared lock first. </p> <p>Note, the upgradeable lock is not exclusive (other shared locks can be held) just that it has special privileges to increase its strength. Unfortunately, multiple upgradeable threads are not allowed at the same time.</p> <p>In your case, the same thread is attempting to use <code>lock_shared</code> and <code>lock_upgrade</code>, which will deadlock. You can rewrite it as below, and it won't deadlock, but it's still a single point of contention for all of the readers, since only 1 will hold the upgrade lock at a time. In which case, depending on your other functions, the complexity of a shared_mutex might not be necessary. However, if other functions are still acquiring shared locks, then the below will perform as you expect.</p> <pre><code>//Multi threaded reader and writer { // Only 1 thread can pass this. Other shared locks are also valid UpgradeLock read(sharedMutex); for (int ii = 0; ii &lt; vec.size(); ++ii) { Element e = vec[ii]; if (e.needsUpdating()) { // Blocks here until all shareds are released WriteLock write(upgrade) //Do stuff } } } </code></pre>
 

Querying!

 
Guidance

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