[RFC] Deferred lock init or lock cookies (hppa spinlock requirements)

[Carlos O'Donell <carlos at systemhalted dot org>]

On Sun, Jul 10, 2005 at 02:58:51PM -0700, Ulrich Drepper wrote:
> I checked in a little bit cleaned up version.

Thanks.

Perhaps I can get your academic opinion on the following?

We are prototyping an NPTL port for hppa. We want to touch as little
core code as possible, and we are thinking of deferred lock
initialization, or scalar cookies.

Deferred Locks:
The core idea is to let the lock acquire fail. On the spin we check to
see if the lock was initialized. Having four lock words means that an
"all zero" lock had been memset to zero, in this case we use a
light-weight-syscall to initialize the lock. The lock held case is
similar.

This saves us from making core code changes that setup the lock to a
different value. It still doesn't save us from using a structure for a
lock word.

Scalar Cookies:
A completely alternative implementation involves using an int lock as a
cookie. The cookies are created dynamically and a lock is materialized
for the cookie.

We have a prototype design using cookies, but we have a couple of issues:

Cookies that are serialized and later reloaded.
	= Requires lock rematerialization.
	= Non-trivial.

Cookies placed in shared memory would need to look at the pshared == 1
case, and place locks into a known named posix shared memory segment.

I know you've had experience with these issue, and I was curious about
your opinion.

c.

NOTE: There is a third alternative, and that is to use the
light-weight-syscall "compare and swap" to do the entire lock
implementation. Performance has not been measured for this case. AFAIK
this is the route HPUX took.