[Thread] Read-write locks
I'm trying to create a standard read/write lock using Boost Threads, and I'm having a bit of difficulty mapping the Boost concepts onto the usual ones. A read/write lock should have several states: Locked for reading (multiple threads may lock at once), locked for writing (only one thread may lock, and no threads may be locked for reading at the same time), and unlocked. Ideally it would be nice if an RWL which is locked for reading may temporarily upgrade to locked for writing, then return to the locked for reading state. Boost supports several relevant notions of locking: shared locking, upgrade locking, and exclusive locking. This to me is a confusing distinction. In particular, a shared_mutex seems appropriate as the basis for a RWL, but is lock_upgrade() the equivalent of a write lock and lock_shared the equivalent of a read lock? This is unclear. If "upgrade locking" is not the same as "exclusive locking", then is an upgrade lock actually exclusive? Could someone please clarify this.
On Thu, Jan 27, 2011 at 2:37 PM, <lfrfly@icqmail.com> wrote:
I'm trying to create a standard read/write lock using Boost Threads, and I'm having a bit of difficulty mapping the Boost concepts onto the usual ones.
A read/write lock should have several states: Locked for reading (multiple threads may lock at once), locked for writing (only one thread may lock, and no threads may be locked for reading at the same time), and unlocked. Ideally it would be nice if an RWL which is locked for reading may temporarily upgrade to locked for writing, then return to the locked for reading state.
Boost supports several relevant notions of locking: shared locking, upgrade locking, and exclusive locking. This to me is a confusing distinction. In particular, a shared_mutex seems appropriate as the basis for a RWL, but is lock_upgrade() the equivalent of a write lock and lock_shared the equivalent of a read lock? This is unclear. If "upgrade locking" is not the same as "exclusive locking", then is an upgrade lock actually exclusive? Could someone please clarify this.
Hi - So you want to use a shared_mutex, and for reading you use a shared_lock, for writing you use a unique_lock, and then if you have a read lock and want to upgrade, you upgrade from a shared to unique lock. Hope that helps, Brian
On Jan 27, 2011, at 5:37 PM, lfrfly@icqmail.com wrote:
I'm trying to create a standard read/write lock using Boost Threads, and I'm having a bit of difficulty mapping the Boost concepts onto the usual ones.
A read/write lock should have several states: Locked for reading (multiple threads may lock at once), locked for writing (only one thread may lock, and no threads may be locked for reading at the same time), and unlocked. Ideally it would be nice if an RWL which is locked for reading may temporarily upgrade to locked for writing, then return to the locked for reading state.
Boost supports several relevant notions of locking: shared locking, upgrade locking, and exclusive locking. This to me is a confusing distinction. In particular, a shared_mutex seems appropriate as the basis for a RWL, but is lock_upgrade() the equivalent of a write lock and lock_shared the equivalent of a read lock? This is unclear. If "upgrade locking" is not the same as "exclusive locking", then is an upgrade lock actually exclusive? Could someone please clarify this.
Here is a description of the original design (with source code) of shared and upgrade locking which the boost versions are based on: http://home.roadrunner.com/~hinnant/mutexes/locking.html This design is slightly different from the boost implementations and imho superior (rationale given in the linked page). It also has many examples. If this document doesn't clear up the concepts and use cases you need, please let me know. -Howard
Le 27/01/11 23:56, Howard Hinnant a écrit :
On Jan 27, 2011, at 5:37 PM, lfrfly@icqmail.com wrote:
I'm trying to create a standard read/write lock using Boost Threads, and I'm having a bit of difficulty mapping the Boost concepts onto the usual ones.
A read/write lock should have several states: Locked for reading (multiple threads may lock at once), locked for writing (only one thread may lock, and no threads may be locked for reading at the same time), and unlocked. Ideally it would be nice if an RWL which is locked for reading may temporarily upgrade to locked for writing, then return to the locked for reading state.
Boost supports several relevant notions of locking: shared locking, upgrade locking, and exclusive locking. This to me is a confusing distinction. In particular, a shared_mutex seems appropriate as the basis for a RWL, but is lock_upgrade() the equivalent of a write lock and lock_shared the equivalent of a read lock? This is unclear. If "upgrade locking" is not the same as "exclusive locking", then is an upgrade lock actually exclusive? Could someone please clarify this. Here is a description of the original design (with source code) of shared and upgrade locking which the boost versions are based on:
http://home.roadrunner.com/~hinnant/mutexes/locking.html This link point at https://home.roadrunner.com/rr/Home_Page_Options.html This design is slightly different from the boost implementations and imho superior (rationale given in the linked page). It also has many examples. If this document doesn't clear up the concepts and use cases you need, please let me know.
Howard please, beside the implementation, have you identified some interface differences between your and the Boost.Thread classes? Thanks in advance, Vicente
participants (4)
-
Brian Budge -
Howard Hinnant -
lfrfly＠icqmail.com -
Vicente J. Botet Escriba