thread-safe local static variable initialization

[Sassan Hazeghi]

Jim: One issue that library providers face, though, is whether they
need to provide a thread-safe in addition to the higher performance
and possibly thread-unsafe version of their library.  I.e. it may
still be helpful to provide a consistent model for library vendors,
possibly at some initialization-time performance overhead, if it
resolves the dilemma (without taxing the application performance
beyond initialization.)

Sassan.

Jim Dehnert writes:
 > 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