Subject: Re: [boost] wait-free fast-pathed, bounded-time, 100% starvation-free rw-mutex...
From: Chris M. Thomasson (cristom_at_[hidden])
Date: 2009-09-04 16:48:53
"Anthony Williams" <anthony.ajw_at_[hidden]> wrote in message
news:87d466n1qh.fsf_at_dell.justsoftwaresolutions.co.uk...
> "Chris M. Thomasson" <cristom_at_[hidden]> writes:
[...]
>>> I still need to test drive the try lock functions in Relacy to see
>>> if I missed anything. As for the `SCHED_OTHER' issue, well, I am not
>>> sure how to get around that without sacrificing the 100% starvation
>>> free and bounded-time guarantees. Humm...
>>
>> I forgot to destroy a resource in the failure case of the
>> constructor. Here is code without the leak:
>>
>> http://pastebin.com/f527722e0
>
> Thanks. Did you try it in Relacy?
No yet. I am going to try and get that accomplished within next couple of
days.
> It looks OK at a quick glance, but I'm not sure I haven't missed anything.
;^)
Humm... Perhaps I should change the name from `fair_mutex' to
`fair_rwmutex'? lol.
http://pastebin.com/f16881bed
(*)
BTW, what are you're thoughts wrt the name change to `fair_rwmutex'? IMVHO,
it sort of implies that the synchronization primitive is `SCHED_OTHER'...
(*)
This code has fixed an issue that only showed up when one attempted to
upgrade a recursively acquired read lock to a write lock. The previous
version would simply deadlock:
______________________________________________________
rw.rdlock();
rw.rdlock();
if (rw.tryrdtowr())
{
rw.wrunlock();
return;
}
rw.rdunlock();
rw.rdunlock();
______________________________________________________
Would deadlock. While the following would not:
______________________________________________________
rw.rdlock();
if (rw.tryrdtowr())
{
rw.wrunlock();
return;
}
rw.rdunlock();
______________________________________________________
Now, both versions will work. The first one with recursive read access will
never be able to upgrade, while the latter might be able to.