Re: Update of threading documentation in chapter 23

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Fri, Oct 05, 2001 at 05:59:21PM -0500, Loren James Rittle wrote:
> Here is an update to the documentation in chapter 23 addressing
> threading issues. ...  
> The
> selection of one locking technique versus another does not directly
> affect the user of the library (other than if it is now changed, a
> non-name mangling incompatibility is introduced - thus it would have
> to be timed for a major gcc release point).

Another way to say this is that for the library to use some brand
of mutex places a dependency on the runtime environment that may be 
incompatible with a user's preference.  We prefer techniques for
low-level library operations (and for operations that may be inlined!)
that depend, where possible, only on the target CPU ABI and that can 
be the same for MT and non-MT code.

In a perfect world we would also have isolated the parts of the 
library that depend on different brands of environmental support, and 
built all the variations, arranging that the (dynamic) linker will 
choose the right one at the latest possible time.  The same might be 
done with math and string operations; one would like to see them take
advantage of instructions not supported on the i386 when the code 
finds itself executing on something more modern.

I gather that ELF, and Linux's and Solaris's dynamic linker, can 
support a great deal of this.  Of course there are many targets that 
don't use ELF and would require earlier bindings.

It seems to me that the approach of building support for all buildable 
(if conflicting) approaches is better than making the user choose one 
at configure time and either playing name mangling tricks to help detect
mismatches, or failing to detect them.  Of course it's more work to do 
it "better", so nobody expects it to happen immediately.

Nathan Myers
ncm at cantrip dot org