Re: [boost] Review Request: boost.lockfree

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
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.