cvs commit: src/lib/libthr/thread thr_pspinlock.c

[Jeff Roberson]

On Tue, 16 Oct 2007, Kris Kennaway wrote:

> Jason Evans wrote:
>> Kris Kennaway wrote:
>>> David Xu wrote:
>>>>   FreeBSD src repository
>>>>
>>>>   Modified files:
>>>>     lib/libthr/thread    thr_pspinlock.c   Log:
>>>>   Reverse the logic of UP and SMP.
>>>>     Submitted by: jasone
>>>>     Revision  Changes    Path
>>>>   1.6       +1 -1      src/lib/libthr/thread/thr_pspinlock.c
>>> 
>>> Are there any common applications that use this?
>> 
>> It's worth mentioning that this change, although correct, does not make a 
>> measurable performance difference for the tests I was running when I found 
>> the bug.  It is possible that making the spinlocks adaptive would help, but 
>> I didn't look into this.
>> 
>> (I was working on malloc performance enhancements that have turned out very 
>> nicely, but in the end I had to switch to hand-rolled "spin" mutexes that 
>> eventually convert to blocking, in order to avoid the possibility of 
>> unrecoverable priority inversion.)
>
> BTW I am looking at adding a non-portable (sort of) pthread mutex type that 
> spins for a while when the lock is held, before blocking.  This is sometimes 
> good for performance when the pthread mutex is highly contended but held for 
> short periods of time, and in fact Linux has such a mutex that is used by 
> mysql with performance benefits.
>
> The real fix would be to make them adaptive in the same way as kernel mutexes 
> (spin as long as the lock holder is running), but there is currently no easy 
> way for userland to peer into the kernel to check the other thread's state.

One thing that was suggested was to spin for a set number of times in 
user-space before entering the syscall which could continue to spin as 
long as the target was running.  The initial few spins would catch quite a 
few cases and avoid the syscall overhead.  Then the spin in kernel could 
last for longer and avoid the switch overhead.  Sort of a hybrid approach.

Jeff

>
> Kris
>