Re: [boost] wait-free fast-pathed, bounded-time, 100% starvation-free rw-mutex...

Subject: Re: [boost] wait-free fast-pathed, bounded-time, 100% starvation-free rw-mutex...
From: Chris M. Thomasson (cristom_at_[hidden])
Date: 2009-08-22 06:43:16

"Andrey Semashev" <andrey.semashev_at_[hidden]> wrote in message 
news:4A8FC4D2.6080206_at_gmail.com...
> DE wrote:
>> on 21.08.2009 at 18:44
>>  Chris M. Thomasson wrote :
>>> I was wondering if the following invention of mine might be of use to 
>>> Boost:
>>> http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822
>>> (please __read_all__; thank you)
>>
>>> do_not_automatically_unlock__very_dangerous_and_deadlock_prone__experts_only()
>> LOOOOOOOOOOOOOOOOOOOL!!!
>> it might be right that!!!
>
> Agreed. :)
>
> I think, support form moving locker guards and delayed locking is the 
> right solution for this need.

I think you are right.

> As for the initial proposal, if it really does fulfill the stated 
> features, I'm all for including it into Boost.Thread.

This version does indeed fulfill all of the stated features/claims:

http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822/reply/87849

However this version:

http://webpages.charter.net/appcore/misc/rwmutex_win_hpp.html

will only support bounded-time starvation-free writer only contention if the 
underlying mutex has said properties. It still will not starve in the sense 
of reads to writes, or even pure reads. But pure writes are at the mercy of 
the underlying mutex implementation.

> However, I'd like to see Anthony's opinion on this.

I hope he thinks it's worthy because IMHO Boost has no room for crappy 
synchronization algorithms...

:^)