16 mutext lock/unlocks per query?
Paul A Vixie
vixie at vix.com
Wed Dec 5 20:32:32 UTC 2001
> > bsd is what we had in our hands at the time we did the design.
> Sadly, I have no such box in my stable to profile...
freebsd and netbsd are both free over the net. both will run on any pc.
> I cannot say whether or not the HP-UX pthread mutext calls are
> "lightweight" or "heavyweight" and the term TSI is not resonating in my
> head, but I do know that under HP-UX, the pthread_mutex_lock and
> pthread_mutex_unlock calls will do their thing entirely in user-space
> unless there is contention for the mutex.
TSI is my generic term for "test and set interlocked", which means some
instruction or sequence of instructions that's guaranteed to succeed for
only one thread regardless of cache pipelines or number of processors.
> When there is contention, you may start to see calls to sched_yield() and
> possibly ksleep and then kwakeup.
then those are the things we should be caring about since the successes
aren't costing you very much, even if there are 15 successes per query.
(with bsd, the gcc "inline" extension is usually used so that you don't
even have the function call overhead on your successes. the phread mutex
calls don't appear to be cpp'able so this matters.)
> The profile should show the syscall stubs for when those things were
> called. As I recall, that was rather rare.
so the lost processor time is all function call overhead unless your TSI
has to empty the cache pipelines rather than snooping them.
More information about the bind-workers