On Wed, 2004-11-24 at 07:05, Steven J. Dovich wrote:

> > You know, I was thinking about this today and was going to ask precisely
> > this question.  (And isn't this what Solaris does/did, at least with the old
> > libthread if not libpthread?)
> 
> Solaris has its own problems in with demand loading a threads
> dependent object at run-time.  They have a libthread implementation
> of sigaction that replaces the libc version, and loading a threaded
> object into a non-threaded application "forgets" what the previously
> installed handler was. This has broken the signal management protocol
> in a commercial application that I work with.

one of the more significant but fortunately less visible changes in
Solaris 10 is that the non-threaded userspace is no more -- libc and
friends always operate in threaded mode with real locking even when
there is only one thread

with respect to mutex lock/unlock in a single-threaded app, the solaris
strategy has been to make uncontended lock/unlock as fast as possible
and then go into slow-path code only if there is contention (already
locked for lock, a waiting thread on unlock).  

In any event, in a non-buggy application with only one thread, there
will be no lock contention -- uncontended locks can go through the same
code path and via weak binding, function pointer, or other tricks
redirect to an abort/assert failure when contention is detected.

						- Bill