compile time constants for selecting thread functionality

[Benjamin Kosnik]

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