Re: RFC: "Generic" gthread model

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> Perhaps we should compile gthr-*.c into separate object files, and
> introduce some option to link in particular thread-support object [...]

Yes!  You have articulated a good position.  A real abstration layer
would be useful here.  Under the assumption that all existing gthr
implementation files could work with that model without losing key
features, I too think it would solve all the issues you raise at a
small price in performance.  For non-multilib platforms without weak
symbols, it might even improve performance in cases where gcc was
installed with thread support but the user links a program that
doesn't use threads (I have no idea how common that case is since I
don't use such a platform)...

Unfortunetely, gthr implementations provided by header support static
initialization of a mutex and ``once cookies'' when supported by the
concrete thread library.  You *absolutely* must support the correct
static initialization of one of those two structures for correct
behavior.

I didn't consider this as well as I should have (from the original RFC):

> Similarly, a long should be sufficient for all reasonable implementations
> of a __pthread_once_t (any system can implement a "once" with only one word
> of data). I have not defined a destructor. Should I? 

Even if we go with the over-sized mutex and ``once cookie'' memory
overlay solution, we still have a problem.  We don't know what *value*
it needs to be set to until binding to the actual concrete thread
library unless we add another layer of indirection (which non-pure
gthr abstraction layer avoids).

Please consider a system that supports:

#define PTHREAD_ONCE_INIT   { PTHREAD_NEEDS_INIT, NULL }

That isn't a long nor is it known to be zero-filled (for this system
it is, but I think that a reasonable implementation that adheres to
POSIX may require some initialization other than zero).  This is from
a reasonable implementation of posix threads.  Solaris is similar:

#define PTHREAD_ONCE_INIT       {0, 0, 0, PTHREAD_ONCE_NOTDONE}

On a POSIX system, the usual mapping for __gthread_once_t is directly
to pthread_once_t.  Was it the original intention that "unknown" would
map directly to the existing, e.g., gthr-posix.h mapping as an option?

In any event: ``You can code your own one-time initialization using a
boolean variable and a statically initialized mutex [or I presume
another implementation of one-time initialization].'' pg. 132
_Programming with POSIX Threads_

But we need to write that translation layer to allow proper mapping to
all existing gthr-*.h files, if we want to go down Alex's approach.

We need to ensure that the performance loss is not great for cases we
care about (it is in the path of STL object allocation and EH).  I
suppose that we will gain that experience once Jonathan's base patch
goes in, no?

Regards,
Loren

PS, Jonathan did explain to me in private e-mail exactly how my posted example
doesn't exactly match hHowever, those statement sort of assume 
is example in more detail.  After breaking t.c into
pieces to make it mirror his case, I see correct results without making
anything weak.  Sorry for any confusion on that matter.