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

[Alfred Perlstein]

* Kris Kennaway <kris at FreeBSD.org> [071016 11:51] 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.

Soon.... :D

-- 
- Alfred Perlstein