Re: [parisc-linux] ldcw in __pthread_acquire

[LaMont Jones <lamont@hp.com>]

> > Note that efficiency *IS ALWAYS LESS IMPORTANT THAN CORRECTNESS*.
> > That's 100%, totally vital!  To say "important" is to make a severe
> > understatement.
> Tell that to the folks I work with at times for whom user space lock testing
> shaves 4 weeks off a run. Try the difference in Mozilla.
> In both cases Im forced to disagree - at least for x86.

Correct appears to be a relative term.  An implementation of semaphores is
correct if it provides mutual exclusion.  Performance becomes a secondary
consideration to that, of course.

I have to side with Alan on this point.  x86 costs too much to go into the
kernel for something that you'll normally not have contention on.  The only
challenge there is that the owner of the resource may hold it for a _long_
time if he gets swapped out, since the kernel has no knowledge.  Note,
however, that it is still correct: eventually, all of the waiters will go
to sleep, and the owner will finally get time to do his thing and free the
sema.

With PA, there's a chance to get into kernel mode cheaply, and it probably
makes sense to do an arch-specific msem_lock() that avoids the heavy
contention issues.

> > Can you interrogate and ask what version of msem_lock() you're calling?  
> Yes. ELF has versioned symbols if they have changed. You can use those for
> many things. X86 however has a stable instruction set abi for locking.

parisc's set is usable as well, but there's a difference in how you code
test-and-set vs test-and-clear.  This makes it a royal pain to port code
that expects test-and-set to parisc...  (And test and inc/dec makes it
even easier...)

> > Although I can't find the man pages for Linux msem_lock, I know that the
> > HP-UX msem_lock doesn't meet all of these criteria (nor does MPE/iX, althou
> > it comes a lot closer).
> We use user space locks for stuff like pthreads on most platforms with
> the kernel doing the contention cases. I'm not arguing that it wouldnt be nic
> to let the kernel do it all if we had cheap syscalls. 

Sounds perfectly reasonable.  How hard is it to put arch-specific things
into that path?

lamont