Subject: Re: [boost] Gauging interest in a thread-safe containers library
From: Eric Greveson (eric_at_[hidden])
Date: 2009-01-14 18:27:58
Thanks for the constructive comments so far!
> IMHO what would be really a nice to have is an (almost) lock-free queue.
Agreed - if a generic thread-safe queue was to be implemented, it
should be lock-free for maximum utility.
> shared_ptr is already thread-safe.
> Did you mean you perform a lock around the access to the wrapped pointer?
Yes, sorry, that's what I meant.
> Why is it tied to shared ownership? This should be distinct things.
> I guess what I'd like to see in boost would be something like a
> boost::monitor<T> which would be like a boost::optional<T> plus monitor
> functionality, and maybe a boost::monitor_ptr<T> which would be a
> boost::shared_ptr<boost::monitor<T> > with some syntactic sugar.
> Why not support operator->()? It would be a convenience.
I haven't used boost::optional myself, but looking at the docs for it,
this sounds like it could be a good way to go. While it's true that
the underlying monitoring / sharing concepts should be distinct, I
think that a convenience class (like the suggested boost::monitor_ptr)
would be useful simply because data sharing between threads in this
way is a common idiom.
> Intel TBB provides that kind of thing already; and there had been discussion of integrating TBB into Boost in the past.
I think that the TBB license means that it can't be integrated with
Boost. The queue provided in TBB is certainly something similar to
what I had in mind, although the interface looks a little bit
> Also, I think it would be worthwhile to follow the concepts of
> Boost.Threads/C++0x with respect to mutexes and locks. That is, make the
> monitor fulfill the Lockable concept, and give your locks the interfaces of
> boost::unique_lock, shared_lock, etc. except with added operator->() and
Sure, that makes sense.
Before going into too much detail on what exactly should be included,
it seems that there is at least some interest in having some more
thread-friendly data structures in Boost. It's true that libraries
like TBB provide some of the required functionality, but I think TBB
might be a bit higher-level (in general) than what could be provided
by Boost. It seems that more than one person has been writing their
own data-sharing monitors/pointers and queues - to my mind these are
fairly basic requirements for several multi-threading scenarios which
should be provided by a standard-ish library.
If we focus on the following as the most common requirements, then:
- monitor / monitor_ptr
- lock-free queue, e.g.
They're obviously not useful in all multi-threaded scenarios, but I
think they would make lots of programmers' lives easier some of the
time. I'd like to hear more reasons for not including these: any
pointers to other libraries that implement these in a portable way,
with the same kind of license as Boost, would be one reason (although
having all your basic threading functionality in One Big Library is
still a bonus).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk