Subject: Re: [boost] Review Request: boost.lockfree
Date: 2009-11-24 15:51:22
Zitat von Tim Blechmann <tim_at_[hidden]>:
> since my first review request for boost.lockfree  was completely
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
> i would like to submit a small library of lock-free data structures for
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
- 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
thanks for posting this, very interesting.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk