Automatic locking for C++ local static initialization

[Jim Dehnert]

As was suggested at the last meeting, I contacted Hans Boehm about
initialization locking to try to clarify why he was opposed to
automatic locking.  We (mostly Hans) worked up this example, which
illustrates one point, that it can produce undeserved deadlocks.

Suppose we have a program written for a pthreads environment that
supports recursive locks (common these days, but not necessary if one
goes to a bit more trouble).  It contains a data cluster
(i.e. a number of interconnected components) that the
programmer wishes to initialize the first time it is referenced,
and the first reference may come through a number of different paths.
One of those paths enters through function f, which defines some static
data, one of which is constructed using function g, which is part of
the cluster; others enter elsewhere and eventually call f.

So the conscientious programmer sets up a mutex lock M, and acquires it
at each potential entry to the cluster before proceeding, which
includes g and some other function h.  Now consider the following
execution sequence:

	Thread 1		Thread 2
	--------		--------
	call h
	acquire M
				call f
				call g
				try to acquire M (wait)
	call f
	call g
	acquire M recursively
	finish initialization
	exit g, f
	release M		
	exit h			acquire M
				initialization is done
				release M
				exit g, f

Everything has worked exactly as the programmer intended.

But now we add automatic locking for the static initialization in F,
say using lock L.  What happens?

	Thread 1		Thread 2
	--------		--------
	call h
	acquire M
				call f
				acquire L
				call g
				try to acquire M (wait, holding L)
	call f
	try to acquire L (wait, holding M)

		DEADLOCK

So I think what we have here is reasonably designed initialization
scenario (at least if you believe in recursive locking) that works as
written, but fails when we insert automatic static initialization
locks.

Other reasons raised earlier, and appearing in the G-4 commentary, are:

 1) There are more efficient methods available to a programmer than
    per-object locks, and doing the latter automatically makes it hard
    to optimize this.

 2) Mike Ball objects that interaction with exceptions can't be
    Standard-conforming with automatic locks.

 3) Hans believes that there are complications with certain legal
    optimizations of the function-scope object initialization.

It would be worth people re-familiarizing themselves with the
commentary (in the Open Issues document) before the meeting.

Jim

-		Jim Dehnert  x3-4272