Subject: Re: [boost] [thread] On shared_mutex
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2010-11-28 19:33:06
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:
> 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.
> Also, there a few references to "diagrams to the right" throughout the text that aren't showing up in my firefox browser. Any suggestions?
Ouch! Do you see any pdf's with the title "Ownership Modes"? If your window width is simply wider or narrow than I'm estimating then these pdfs may be higher or lower in the text flow. However if there is something about firefox that won't display these pdfs at all then I need to do something else (maybe convert them to jpegs).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk