Re: [boost] Gauging interest in a thread-safe containers library

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.
and
> 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.
and
> 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
bloaty...

> 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
> operator*().

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).

cheers

Eric