Subject: Re: [boost] [thread] upgrading read lock to write lock
From: Edd Dawson (lists_at_[hidden])
Date: 2011-02-06 20:04:43
On 2/6/2011 11:51 PM, Howard Hinnant wrote:
> On Feb 6, 2011, at 5:10 PM, Peter Dimov wrote:
>> Howard Hinnant wrote:
>>> int main()
>>> ting::upgrade_mutex m;
>>> ting::upgrade_lock<ting::upgrade_mutex> readlock(m);
>>> // reads go here
>> The problem is that only one thread can do this at a time, and I suspect that in the original problems, there are many such readers, some of which need to then write, but only occasionally.
What I'm trying to achieve is to be able to turn a read lock in to a write lock
without forfeiting my 'turn'.
Specifically, I'm implementing a kind of thread-local storage. In order to do
so, I have a map whose keys are thread::ids. I'd like to take a read lock while
looking to see if there's something in the map for the current thread and if so,
return the associated value. Otherwise, I want to upgrade to a write lock so I
can fill in a value for the current thread before returning it.
I guess I'd like to know:
1. Is this a realistic thing to expect to be able to achieve? I'm under the
impression that this is the purpose of an upgradable locking facility. Perhaps
this isn't the case, though?
2. The boost-centric code that I posted was my attempt at doing this. What makes
> Yes, there are several tools in the tool box here. And none of them are the right tool for all situations. The upgradable lock tends to be most needed when the read is expensive enough that you want to put extra effort into not repeating it.
It may be the case that my approach to the problem will result in an inefficient
solution, but I'd like to at least understand the correctness problems, before
continuing much further.
And Howard, thanks for sharing your ting implementation elsewhere in the thread.
For what it's worth I approve of the separate upgrade_mutex and may consider
using this instead, in the end. Thanks for sharing!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk