Boost logo

Boost :

Subject: Re: [boost] [lockfree] how many items are queued?
From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2009-09-04 20:59:55


Yes and no. empty() and esp size() are not generally useful in mutlti-
threaded code, but they're not useless.

There are some points in a threaded program where you *know* that no
other thread can add or remove from a queue, because you design your
application and know what your threads are doing. Perhaps you're
(temporarily) under lock. And in those moments I don't see a problem
with calling empty() or even size() (maybe you need it as a hint for
dimensioning some buffers). And I wouldn't want to have a heavy-duty
lock or other guarantee to make the result correct either.

What's IMHO the correct response for empty(), size(), and other (non-
thread-safe) functions is to document explicitly:

bool empty() const;
   // Return whether a *snapshot* of this queue is empty.

size_t size() const;
   // Return a *snapshot* of the size of this queue.

And that's only if you can implement it atomically, of course. If
you have to iterate or do a calculation, then even the documentation
of size() could be wrong (there may never be a snapshot of the queue
that has that size). And in that case, I wouldn't provide size() at
all, fwiw.

My $0.02,

--
Hervé Brönnimann
hervebronnimann_at_[hidden]
On Sep 4, 2009, at 5:46 AM, Manuel Fiorelli wrote:
> 2009/9/4 Tim Blechmann <tim_at_[hidden]>:
>> well, the user of the library has to make sure, that this function is
>> not used in places, where a concurrent access to the queue is  
>> possible ...
>> but, well, even _if_ it would be possible to atomically check,  
>> whether a
>> stack/queue is empty, the result is not valid any more, at the time,
>> when you use the result:
>
> Interesting observation: the result of empty() would be useless in  
> any case.
>
> Manuel Fiorelli
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/ 
> listinfo.cgi/boost

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk