----- Original Message ----
From: Tim Blechmann <tim@klingt.org> To: boost@lists.boost.org 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