Eric Haszlakiewicz <erh@nimenees.com> writes:

> 	So why don't we initialize them then?  I can see how we would want to
> avoid taking the performance hit on locking for programs that don't need
> it, but wouldn't the impact of initialization be much smaller? 

Initialization is something of a red herring; static initialization of
mutexes and condvars does happen without libpthread linked in.

The bigger problem is that you don't know what state things are
supposed to be in. Consider a sequence (which I've seen) that is
effectively like:

  mutex_lock()

  dlopen("libpthread.so")

  mutex_unlock()

For this to work at all, the dlopen() has to cause the mutex routines
to bind to the real thing, which itself will take some ld.so
trickiness we don't have yet (or another layer of indirection in libc,
which slows down both threaded and nonthreaded programs). But once
that's working, the mutex_unlock() will be unlocking something that
was operated on by a dummy mutex_lock(). There's no way that the code
can magically know which bits of memory are suddenly supposed to
become locked mutexes.

There are other variations on this scenario, and none of them are pretty.

        - Nathan