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

Subject: Re: [boost] Gauging interest in a thread-safe containers library
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-10 13:00:15

----- Original Message ----- 
From: "Eric Greveson" <eric_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, January 15, 2009 12:27 AM
Subject: Re: [boost] Gauging interest in a thread-safe containers 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).

Hi,

I don't think there is any reason to don't include any feature in Boost. AFAIK, a lot of posts talk about these extension but no body has push until proposing a library for review. I'm working on a Sync library including:
  a.. Lock traits: very specific traits classes, some of them encapsulate a single trait for a Lockable type; for example, is a lock recursive (is_recursive), is useful in a multi threaded context (is_multi_threaded). 
  b.. Finding the best lock: Inverse traits can match a lockable type based on specific traits, for a given family of lock types. 
  c.. Synchronization family: A class that will do internal locking can be parameterized by the type of synchronization family needed to achieve the desired level of concurrency control. This depends of the usage scope of this class, and this can be mono_threaded, multi_threaded, multi_process. 
  d.. Strict lockers: A strict_locker is a scoped lock guard ensuring the mutex is locked on the scope of the lock, by locking the mutex on construction and unlocking it on destruction. 
  e.. External lockers: An alternative or complementary approach to internal locking is to support external locking for an object - Multiple calls may be grouped within the same externally defined critical region. 
  f.. Reverse locker: reverse_lock. 
  g.. Concurrent components may interact in different ways: they may access the same objects by, for example, executing functions of these objects; or they may communicate directly by executing functions of each other. This library includes monitor for guaranteeing exclusive access to an object and also the so-called rendezvous mechanism for handling direct communication between active objects.

For the moment all this is an draft state. You can get them from the Sandbox. https://svn.boost.org/svn/boost/sandbox/synchro

I'll try to put something on the Vault this week.

Best,
Vicente