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