Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-07-24 05:06:48

> I think the semantic's should be equal to that of std::containers, when
> possible. How about a compromise:
> 
> void enqueue(const T&) throw(...)
> void try_enqueue(const T&) // no throw guarantee if T's copy constructor
> is no throw guarantee

this sounds reasonable ... btw, the fifo is limited to PODs, so try_enqueue 
would never throw.

> Have you considered proposing your lockfree algorithms and datastructures
> as part of boost::intrusive? To me, using intrusive datastructures would
> be preferable in performance critical scenarios, and it's an excellent way
> of guaranteeing a non-throwing/non-failing enqueue operation (since the
> user can avoid the copy constructor all-together). A higher-level
> container such as the current lockfree:fifo could then be built upon such
> a foundation.

i have the fear that this would be rather dangerous. objects wouldn't be 
allowed to be destroyed, while any fifo operation takes place. if thread a 
dequeues and destroys an object, thread b may still have a local pointer to 
it and may try to dereference this pointer ... with intrusive data 
structures, this would be the responsibility of the user ... a rather subtle 
source of an error. while i am a big fan of intrusive data structures in 
general, but not for lock-free data structures

tim

-- 
tim_at_[hidden]
http://tim.klingt.org
A paranoid is a man who knows a little of what's going on.
  William S. Burroughs