"The implementation must not introduce any deadlocks around execution of the initializer that are not implied by the program semantics"

I don't think that's clearer personally. As a frequent reader of standardese, "the implementation must not introduce" already means that it's not talking about deadlocks caused by the programmer. Furthermore, the implementation doesn't introduce deadlocks implied by the program logic, the programmer does.

How about adding a second sentence, rather than extending the first? e.g.

"The implementation must not introduce any deadlocks around execution of the initializer. This does not preclude deadlocks being caused by the program logic; the implementation need only avoid deadlocks due to its own synchronization operations."

I'm not particularly attached to my rewording. I don't really like the extra sentence you added either though. I think that sentence has about as much subtlety as the original foot note, and I want to reduce the subtlety.

As a programmer, I need to know what locks are in the system so I can manage my lock hierarchy correctly. The standard implies behavior here, but I would much prefer that the behavior be stated more directly, even if that is just in some non-normative note or example.

I think what I'm looking for is a more obvious statement as to the locking behaviors that are permitted by the standard. The standard permits a per-object lock around initialization, and it permits implementations that simulate a per-object lock. The standard doesn't permit a single global lock.

I was under the impression that the standard does allow a singe global recursive mutex for statics. Which situation would come up with that where the deadlock rule is violated?

I was under the impression that the standard does allow a singe global recursive mutex for statics. Which situation would come up with that where the deadlock rule is violated?

Suppose I have my own global mutex. In thread 1, I lock my mutex, then call into a function with a function-level static of type Foo (my_foo). In thread 2, I call into a function with an independent function-level static of type LockedFoo (my_locked_foo). The constructor of LockedFoo grabs the global mutex.

If the construction of my_foo and my_locked_foo are both guarded by the same global recursive mutex, then you get a deadlock. If they have (effectively) different mutexes, then you don't have a deadlock. This deadlock isn't implied by the program semantics.

@ben-craig: Thanks for the explanation. Since the standard is a specification, we try not to preclude novel implementations that nobody thought about before. So, I do like @jwakely additional sentence (slightly refurbished) instead of expressly talking about specific locking techniques.