Raoul Gough wrote:
- thread-safe queue (no immediate need, but is likely to arise in future)
I implemented a thread-safe queue on top of Boost.Threads about 18 months ago. It has a locking proxy that provides access to the raw container, as well as providing block-on-empty and block-on-full operations. e.g.
// typedef mt::safe_queue<std::deque<Element> > queue_type; // queue_type *g_queue_ptr;
{ queue_type::proxy_type const &proxy (g_queue_ptr->get_proxy()); // Locks mutex. Noncompliant because scoped_lock is noncopyable // but works on gcc at least. This could be made compliant e.g. // using shared_ptr<proxy_type>
Hmm.. I don't see scoped_ptr anywhere in the example?
proxy.block_while_empty (timeout); // Uses timed_wait (temporarily releases lock)
while (!proxy->empty()) // Accesses raw container { // ... proxy->pop_front(); // Accesses raw container }
I guess proxy's operator-> locks the mutex. Hmm... what happens if 1. The proxy->empty() returns false. 2. Another thread, using the fact that mutex is not locked now, extracts all the elements from queue. 3. The first thread executes proxy->pop_front() I might be missing something, but is wrapping of all operation in mutex (i.e. making them synchronized in Java-speak), makes the resulting container sufficiently safe? - Volodya