Subject: Re: [boost] [thread] On shared_mutex
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-28 21:27:41
On 11/28/2010 4:33 PM, Howard Hinnant wrote:
> On Nov 28, 2010, at 7:07 PM, Jeffrey Lee Hellrung, Jr. wrote:
>
>> Next topic:
>>
>> I'm now confused with the implementation of try_lock_until...let's start with the first line:
>>
>> std::unique_lock<L0> u0(l0, t)
>>
>> So...L0 is itself a lock (specifically an ExclusiveLock, I would guess, although the second implementation of average is using a "Lock"...typo?),
>
> Yes, type-o. Thanks for catching that! Each of those Lock's should be ExclusiveLock. My intent was to reuse A's typedefs from a few paragraphs above. I've updated:
>
> http://home.roadrunner.com/~hinnant/mutexes/locking.html#Upgrade
>
>> so I don't think this makes sense. Should be something like l0.try_lock_until(t) ???
>
> Actually no. This is one of the things that makes generic locking algorithms so cool. L0 is what we now call Lockable (thanks to Anthony), or maybe more correctly TimedLockable. L0 could be a mutex, or could be a lock. This algorithm doesn't know or care. Either way it creates the lock: std::unique_lock<L0>. And the constructor called by:
>
> std::unique_lock<L0> u0(l0, t);
>
> will internally call l0.try_lock_until(t). Both std::unique_lock, and std::timed_mutex support this syntax, as do also ting::shared_lock, ting::shared_mutex, etc.
>
> The reason to wrap L0 up in std::unique_lock<L0> is exception safety. If l1.try_lock_until(t) either returns false or throws, then u0.~std::unique_lock<L0>() unlocks l0 on the way out. That way you get either all or none L's locked on normal or exceptional return of try_lock_until.
Got it.
Please excuse the basic concurrent programming questions, I just want to
make sure I understand the exposition correctly...
It looks like this implementation of try_lock_until could "fail" under
contention, i.e., neither contending thread would perform the averaging
computation. Suppose thread 1 calls a1.average(a2) and, simultaneously,
thread 2 calls a2.average(a1). It could happen that thread 1 locks
a1.mut_ in the first line of try_lock_until, and thread 2 similarly
locks a2.mut_, and then each thread is waiting to acquire the other
mutex. Now they both time out waiting for the other mutex before either
is able to unlock their held mutex, so neither thread enters the average
computation. Is this accurate? If so, this seems undesirable, though
it isn't nearly as bad as a deadlock scenario. Is it possible to
guarantee this won't happen?
Up to this point, the proposed changes to the Boost.Thread
synchronization concepts and types look reasonable, but I haven't done
anything too advanced with mutexes ever...
- Jeff