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@klingt.org http://tim.klingt.org A paranoid is a man who knows a little of what's going on. William S. Burroughs