Re: [boost] [Review] Lockfree review starts today, July 18th

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 
>i 
>
> mention that in some cases blocking data structures can outperform their  
lock-
> 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"

Artyom