Re: [boost] [thread] upgrading read lock to write lock

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 
it wrong?

> 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!

Kind regards,

Edd