Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-07-25 08:29:52

>>> 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?

it probably is ... i am currently working on it ...

>>> 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?

mpl could be used for selecting the specific implementation ... otoh, it 
will hide the additional complexity behind the interface. in some cases, it 
may be feasible to adapt the used classes instead ...

>>> 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?

well, one thing, that i didn't think of, is alignment ... on some 
architectures, cas-able memory regions need to be aligned ...

>>> 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.

done

tim

-- 
tim_at_[hidden]
http://tim.klingt.org
When you open windows, bugs get in.