[boost] Re: Future of Boost.Thread part II

From: Raoul Gough (RaoulGough_at_[hidden])
Date: 2004-02-11 13:01:35

Vladimir Prus <ghost_at_[hidden]> writes:

> Michael Glassford wrote:
>
>>> I do need to set thread priorities however.
>>> This is more important to me than cancellation.
>> 
>> This leads me to ask, while the interest sparked by the "Future of
>> Boost.Thread" thread is still hot: what are the most important things,
>> in your opinion, that Boost.Thread lacks?
>
> With the caveat that I do not use threads all that much, I can ask for
> - barrier (needed it recently, and besides, it's already on thread_dev
> branch).
> - 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>

  proxy.block_while_empty (timeout);
  // Uses timed_wait (temporarily releases lock)

  while (!proxy->empty()) // Accesses raw container
    {
      // ...
      proxy->pop_front();  // Accesses raw container
    }
} // Proxy destructor uses notify_one or notify_all

The proxy destructor detects changes in the size of the container and
notifies the queue's full or empty mutex as appropriate. I'm sure
there are other and probably better implementations out there, but I
guess blocking read/write would be a pretty common requirement...

-- 
Raoul Gough.
export LESS='-X'