[9fans] Semaphores in Plan 9

[9fans] Semaphores in Plan 9

[Nick Owens]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

in Semaphores in Plan 9 [1] a test is described comparing
semaphore-based locks to tas-based spinlocks. the paper says they ran
"doug's power series program" using the different lock types in
libthread for channels. i was trying to reproduce the results in the
test, and my naive attemps don't fare well for semaphores.

so, is the test code available anywhere? or has anyone written a
comparable benchmark which favors semaphore-based locks?

[1] http://doc.cat-v.org/plan_9/IWP9/2008/semaphores.pdf


[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [9fans] Semaphores in Plan 9

[erik quanstrom]

On Wed Jun 11 20:26:49 EDT 2014, mischief@9.offblast.org wrote:

> in Semaphores in Plan 9 [1] a test is described comparing
> semaphore-based locks to tas-based spinlocks. the paper says they ran
> "doug's power series program" using the different lock types in
> libthread for channels. i was trying to reproduce the results in the
> test, and my naive attemps don't fare well for semaphores.
> 
> so, is the test code available anywhere? or has anyone written a
> comparable benchmark which favors semaphore-based locks?

i don't have the power series code, but...

i spent quite a bit of time on this issue, and generally semaphore
based locks look quite bad.  the reason is very simple.  the syscall
takes ~1µs.  the hazards protected by locks aren't generally this big.
a µs is a long time.

there's another reason that's subtle, and makes analysis hard.
the semaphores are fair, while the user-level tas locks are grossly
unfair.  that unfairness inflates the operations per second because
one processor keeps reacquiring the lock, while others lose out.
so it's like running the program n times sequentially, rather than
running concurrently on n processors.

i'm not sure what the answer is.

- erik