thread-safe local static variable initialization

[Jim Dehnert]

Thanks for the clarification.  I understand now, and have added the
issue as G-4.  However, I share Mike's scepticism about tackling the
problem, for reasons I'll explain below.

> From: jls at sco.com (Jonathan Schilling)
> Date: Mon, 7 Jun 1999 19:54 EDT
> 
> The standard is mute on multiple threads of control in general, so 
> there is no requirement in the language to support what I'm talking
> about. But as a practical matter compilers have to do it (Watcom gave
> a paper on their approach during the standardization process, if I
> remember).

It's not obvious to me that compilers have to do it.  As Mike points
out, it is permissible to leave the responsibility to the users.  And,
I'm inclined to believe that's the right solution.  What it would take
to change my mind would be a solution which addressed the following
concerns:

First, it should not cause noticible cost in non-multithreaded
programs.

Second, it should not cause unnecessary cost in multithreaded programs.
This requires more elaboration.  Even in multithreaded programs, I
would guess that most relevant initializations would not really be
exposed to multiple simultaneous executions, and a careful user could
avoid locking.  Further, in many of the remaining cases, I would expect
a careful user to be able to use a single lock for a collection of
object initializations, giving the per-object locking I would expect
from an automatic approach higher overhead than necessary.

Of course, the argument might be made that doing this automatically
simplifies the life of the multithreading programmer, but I suspect
that's less useful than it appears.  This particular case (explicit
dynamic initialization of local static variables) is a relatively minor
example of a whole class of program behaviors subject to the same
issues, where most of them are strictly user code cases that the
compiler has no chance of identifying, let alone solving.  So the user
is going to have to be aware of these issues and their solutions
anyway, and leaving this example to him doesn't seem onerous.


However, it's not very effective to discuss the problem in the
abstract.  If someone has a specific proposal for solving the problem,
submit it, and we can discuss concrete characteristics instead of
speculations.


-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272