Zitat von Tim Blechmann <tim@klingt.org>:
since my first review request for boost.lockfree [1] was completely ignored
I have stated that multiple times, I think a mailing list is the wrong format for boost. important posts are missed in the noise. is this still a mailing list for historical reasons only or was there a decision against a message board? to your library, I have a few pre-review comments and questions if you don't mind:
i would like to submit a small library of lock-free data structures for review.
could you post a link that lists known lock-free data structures so people not already familiar with lock-free data structures can see how your library matches that?
boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack
I only had a look at the documentation sor far. there are a few things I found surprising: - noncopyable: is the only reason for this that containers can't be copied atomically? - fifo: the STL fifo is called std::queue and has a very different interface than your fifo class. I guess you have to change some things, e.g. std::queue::pop() has a void result, but it could resemble the STL interface, can't it? - that free_list thing...looks very much like an allocator. I understand that you want to make sure that push/pop doesn't call the default allocator (-> mutex lock), but couldn't you make lock-free containers accept stateful allocators and provide a default allocator that keeps free-d objects in a free_list? am I missing a reason why you need a seperate allocation interface? I haven't found the concept the free_list_t template parameter in the documentation, can it do anythiong beyond what the interface of a std::allocator provides? thanks for posting this, very interesting.