Deferred lock init or lock cookies (hppa spinlock requirements)

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.

_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux