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?
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk