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@mac.com On Sep 4, 2009, at 5:46 AM, Manuel Fiorelli wrote:
2009/9/4 Tim Blechmann <tim@klingt.org>:
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