Boost logo

Boost :

Subject: [boost] [thread] Dividing into Boost.Thread and Boost.Sync
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-08-17 07:27:43


Hi,

In our private conversation Vicente J. Botet Escriba, Tim Blechmann and myself
have formed a proposal to split the current Boost.Thread library into two
libraries: Boost.Thread and Boost.Sync. The former will retain its thread
management features, such as thread class, futures and TLS. The latter will
contain all thread synchronization components, such as:

 - locks
 - mutexes
 - condition variables
 - call_once

Mutexes and condition variables in Boost.Sync will not support thread
interruption and will be as simple and lightweight as possible. For example,
one of the benefits I'd like to achieve with this is that synchronization
primitives should become decoupled from the timing libraries.

I'm not sure we'll be able to make the whole library header-only, but we will
try to. If some component is header-only, it will not require linking to
Boost.Sync.

We plan to add new components to Boost.Sync after the extraction is made. The
current candidates for addition are:

 - spin_mutex and yield_spin_mutex. There are several implementations in
Boost, namely in Boost.SmartPtr, Boost.Log and Boost.Atomic. The plan is to
refine them into two flavors of spin mutex and move to Boost.Sync and then
switch these libraries to the common implementation, if possible.
 - once blocks from Boost.Log.
 - portable Windows-style events. There is a prototype implementation in
Boost.Log.

Boost.Thread will depend on Boost.Sync and will retain headers and possible
glue code for backward compatibility. For instance, I think it will have to
implement interruptible condition variable.

Comments are welcome.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk