Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Edd Dawson (lists_at_[hidden])
Date: 2010-07-25 07:25:24

On 7/24/2010 3:49 PM, Tim Blechmann wrote:

>> I think it would be nice to propagate the links to the data structure
>> references up to the contents page. Right now they appear to be 'hidden'
>> under introduction.
>
> not sure, how this can easily be achieved with quickbook ... any pointers?

Sorry, I have no experience with quickbook :(

>> Specifically speaking about
>> http://tim.klingt.org/boost_lockfree/boost/lockfree/fifo.html, now:
>>
>> 0. "It uses a freelist for memory management, freed nodes are pushed to
>> the freelist, but not returned to the os. This may result in leaking
>> memory." Presumably this means memory may not be reclaimed until the fifo
>> is destroyed, rather than an indefinite leak?
>
> yes.

In that case, I wonder if it's worth rephrasing those notes?

>
>> 1. "Limitation: The fifo class is limited to PODs". I really would like to
>> be able to use this with arbitrary objects. I'm sure PODs are required for
>> good reason, but a rationale somewhere would be greatly appreciated.
>
> it is a limitation of the michael/scott algorithm. if you want to pass non-
> pods, you have to use heap-allocated pointers.

Ok. But then would it be worth having a version of a fifo that does the 
heap-allocation indirection, to save everybody from re-writing it every time 
they need a non-POD fifo?

>> 2. For the is_lock_free() method, it says "Warning: It only checks, if the
>> fifo head node is lockfree. on most platforms, this should be sufficient,
>> though". Sufficient for what? If the implementation can't guarantee
>> lock-free behaviour throughout, I'd simply return false. Lock-free
>> (typically) means something very specific, after all.
>
> the c++0x semantics of atomics, provide a per-object member function. all
> implementations thati am familiar with will always either provide lockfree
> cas operations for all atomic<>  instances or for no. the current
> implementation will give a hint. otherwise i can simply remove this function
> from the interface ...

I see. FWIW, I can't imagine that an implementation would restrict the number of 
atomic<>s that provide a lock-free CAS. That's probably your reasoning too I 
guess. Is this something that can be clarified by the authors of Boost.Atomic?

>> 3. For the empty() method, it says "Not thread-safe, use for debugging
>> purposes only". Does this mean calling it might destroy the data
>> structure's invariants? Or is it always safe in that regard? In which
>> scenarios can it be used, specifically?
>
> calling it may return a wrong result. the data structure is not corrupted.

Then I would vote to add such a note to the documentation, clarifying the way in 
which it's not thread-safe. It could still be useful for some cases outside of 
debugging.

Kind regards,

Edd