This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
compile time constants for selecting thread functionality
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Fri, 1 Sep 2006 17:33:17 +0200
- Subject: compile time constants for selecting thread functionality
I'm a bit stumped right now. I'm trying to consolidate the various
compile time constants that currently exist to specify specializations
for threaded, type of threaded, and single-threaded code.
This started with this bit from
include/tr1/boost_shared_ptr.h:
// TODO This should go into a separate header really.
enum _Lock_policy { _S_lockfree, _S_mutex, _S_single };
static const _Lock_policy __shared_ptr_default_lock_mode =
#ifdef __GTHREADS
// NOTE: This doesn't actually exist yet in the compiler.
#ifdef _GLIBCXX_ATOMIC_BUILTINS
_S_lockfree;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
// END TODO
Great, I thought. I should be able to use this, or something like this, to replace:
include/ext/mt_allocator.h:
#define __thread_default true
include/ext/bitmap_allocator.h:
bool const __threads_enabled = __gthread_active_p()
There are also atomic and mutex usage patterns in locale and string
parts of the library.
Let's stick it in bits/atomicity.h, figure out consistent usage, do the
changes, and see what breaks!
Not so easy, as it turns out.
There may be others, but to me it seems sensible to think this through
now. It would be nice to have some kind of consistency throughout the
library. Then, there would be no re-inventing the wheel in every
file, and sane documentation and usage guidelines will be possible.
>From the above uses, I can piece together the following uses:
1) is threading supported at all on this target?
2) is threading supported and currently active?
3) assume threading active, prefer mutexes to do MT-safe stuff. (only mutexes?)
4) assume threading active, prefer atomics to do MT-safe stuff. (only atomic?)
5) ? (mix atomic + mutex?)
Currently, boost_shared_ptr.h has very inconsistent usage. Examples
include using atomics in single-threaded specializations or code paths,
atomic read/write barriers in mutex code, __weak_ptr::lock which could
be re-written for a single-thread/multi-thread boolean, etc.
mt_allocator has its own issue, in that currently there is only the
single-thread/multi-thread duality. (I believe we can hack around this
by casting _S_single as the first enum to bool.) However, the question
remains: do we want to have the option of lock-free pools versus
mutex-locked pools? (I would say yes.)
If there exists cases where compile-time template specialization makes
sense for the single-thread/multi-thread duality, then I think a bool
is our best bet. Then, an additional enumerated type could be used to
select between locking strategies. Otherwise, we'll have duplication
between code for thread models.
?
-benjamin