Re: [boost] boost.lockfree update

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

On 7/23/2010 12:24 PM, Tim Blechmann wrote:
 > [2] http://tim.klingt.org/boost_lockfree/

Hi Tim,

I'd be very interested in using this library when it's "done". For now, I've 
only skimmed the documentation, but here are some initial comments.

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.

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?

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.

Or, would it be possible to provide an additional class that would work with any 
kind of object, possibly with a performance penalty (and modified interface for 
exception safety)? If so, I'd vote to make lockfree::fifo the general data 
structure and perhaps lockfree::pod_fifo the one with POD-specific optimizations.

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.

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?

If I'm using a fifo as a work queue, I can imagine that an empty() method that 
is safe from an invariant-maintenance point of view could be useful in a 
heuristic to decide whether I should go do something else for a while.

In either case, I'd be more specific about what's meant by not thread-safe. But 
presumably it would be possible to write a thread-safe version given that 
dequeue can return false? If so, I'd remove/rename/hide this function.

4. "bool dequeue(T * ret);". Using a reference rather than a pointer has been 
mentioned else-thread. That would also be my preference.

Analogous comments apply to some areas of the documentation for the other data 
structures too.

Cheers,

Edd