thread-safe local static variable initialization

[Jonathan Schilling]

> From: Hans Boehm <boehm at hoh.engr.sgi.com>
> Message-Id: <9906101554.ZM3948 at hoh.engr.sgi.com>
> Date: Thu, 10 Jun 1999 15:54:23 -0700
> To: cxx-abi at corp.sgi.com
> Subject: Re: thread-safe local static variable initialization
> 
> I'd like to make some claims about function scope static constructor calls in
> multithreaded environments.  [...]
> 
> I believe that these arguments imply that this problem is not important
> enough to warrant added ABI complexity or overhead for sequential code.

This response is a little tardy, but --

Hans' argument breaks such local statics into two groups:  those that don't
depend upon the function's parameters, and those that do.  For the latter
group, he says:

> 6) Static function scope constructor calls which depend on function arguments
> are likely to involve a race condition anyway, if multiple instances of
> the function can be invoked concurrently.  Any of the calls might determine
> the constructor parameters.  Thus these aren't very interesting either.
> And if they are really needed, they can be replaced with a file scope static
> constructor call plus an assignment.

I don't agree with these claims.  There are sometimes situations where a group
of objects is being processed, and you want to arbitrarily pick one of them
to serve as an identifier or key for all of them.  Consider perhaps a golf 
course scheduler, which is taking in players and assigning them to foursomes.  
You want to name each foursome by one of the names of the players (it doesn't 
matter which one), such as the "Jones group" or the "Smith group".  
A natural way to program this might be:

	void build_foursome(string golfer) {
		static string group_name(golfer);
		// process golfer into group group_name ...
	}

Now if the golfers being scheduled are coming from four different
databases, it might be that a thread is running to extract from each
database.  Thus build_foursome() might be called concurrently.  That's
fine, and there is no need for application-level locks in either the 
caller or this function; we don't care which golfer the group is 
named after.  We just want the 'static' to work correctly; what we
don't want is a double initialization, with two different group names
being generated for golfers in the same group, which is possible if
the guard code isn't thread-safe.

Now one can say that this kind of design isn't wise, or that locks will 
probably be needed later in this function to do the rest of the processing, 
or that this can be coded in several other ways.  And that may all be so.
But I think this usage is *reasonable* in this context, and that as 
implementors we should get it right.  [Editorial:  Especially with the 
advent of Java, threaded application programming is becoming more the norm; 
and language implementations that dodge the challenge and say that thread
support is solely the job of libraries, may not be looked upon kindly
by users.]

Jonathan Schilling		SCO, Inc.		jls at sco.com