Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-07-23 18:01:17

>> one shouldn't try to en/dequeue from one thread, while another thread is
>> running the constructor/destuctor. maybe it should formulated in a better
>> way ...
>>
>>
> Operating on a deleted object is always undefined behaviour. I think it's
> not related to lockfree datastructures.

true

>> > bool enqueue(T const & t);
>> > Shouldn't this function throw an exception if t cannot be enqueued?
>>
>> i would prefer not to throw an exception! if a constant-size freelist is
>> used, the enqueue operation may fail, although no `error' occurred. i
>> prefer
>> this interface
>>
>>
>>
> If memory for the operation cannot be obtained, I believe common practice
> is to throw an exception. IMO, it does not matter if a fixed size pool is
> exhausted or the global heap, since the effect is the same -> a no op.
> With current interface I'd need to always check return value for every
> enqueue for out of memory conditions, something I don't need to do with
> any other container.

true ... but if you use the fixed-size memory pool, you would have to add a 
try/catch block ...

>> > bool empty(void) //warning Not thread-safe
>> > I think this function should be removed from public interface if it
>> cannot
>> > be implemented in a thread safe manner.
>>
>> i would prefer to keep it, but warn about the thread safety. i am also
>> thinking about adding thread-unsafe version of enqueue/dequeue/push/pop,
>> since they can be implemented in a more efficient way than the
>> thread-safe versions.
>> one can think of a use case, that one thread fills a fifo/queue and then
>> notifies consumer threads ...
>>
>> Would if suffice to add another constructor for that?
> template<class Iterator>
> fifo(Iterator first, Iterator last)
> 
> Then you can have an optimized way of populating the lockfree
> container,without adding unsafe member functions.

for my most important use case, this would not be sufficient. during some 
times, i am accessing my fifos from a single thread only, during other times 
by multiple threads ...

cheers, tim

-- 
tim_at_[hidden]
http://tim.klingt.org
Silence is only frightening to people who are compulsively
verbalizing.
  William S. Burroughs