Subject: Re: [boost] [Review] Lockfree review starts today, July 18th
From: Artyom Beilis (artyomtnk_at_[hidden])
Date: 2011-07-19 15:01:44
----- Original Message ----
> From: Tim Blechmann <tim_at_[hidden]>
> To: boost_at_[hidden]
> Sent: Tue, July 19, 2011 9:10:06 PM
> Subject: Re: [boost] [Review] Lockfree review starts today, July 18th
> hi julien,
> > ** On lock-free concepts in general
> > - Your definition of obstruction-free is strange, I would have though
> > that a lock free structure would be quite the opposite :* "if a concurrent
> > operation is guaranteed to be finished in a finite number of steps, even
> > if* * another concurrent operation interferes"*. I do not understand the
> > guarantee that obstruction gives otherwise. I think this section of the
> > documentation should be expanded and give more details.
> i am basically taking the definitions from herlihy&shavit. but i can try to
> improve this part of the docs.
Actually reading this notes I opened Herlihy & Shavit book
"The art of multiprocessor programming"
To check if this is correct definition and then I had seen you refer
to the book.
Which actually gives +1 to the library even more.
> > ** About performance
> > - You don't mention in the "motivations" sections that lock-free data
> > structures are probably more performant than their locked counter parts.
> > Though it is obvious too some, it is not to all, and to be honest, I'd
> > prefer you mention at this stage the typical usage of lock free structures
> > (for instance, are there situations where locked data structures perform
> > better ?)
> there is a section about `performance of non-blocking data structures'. there
> mention that in some cases blocking data structures can outperform their
> free equivalent.
I must strongly support this point. Lock free is not always the
fastest algorithm but in some cases it is may be very important
to ensure conditions like "at-least-one-succeeds-eventually"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk