Boost logo

Boost :

Subject: Re: [boost] Review Request: boost.lockfree
From: strasser_at_[hidden]
Date: 2009-11-24 15:51:22

Zitat von Tim Blechmann <tim_at_[hidden]>:

> since my first review request for boost.lockfree [1] 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
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at