>>not available, the process would lower its priority and wait.  There was no mechanism
>>to hurry the process holding the lock along while (for example) a real-time process was
>>waiting.  We changed the scheduler:  Now, a process holding a lock (NOT a qlock) is
>>not scheduled until it gives up the lock.  We think this is one of the causes for the
>>faster feel of the system -> less thrashing.

i had idly wondered about that bit: it didn't seem canonical.  serve me right for being idle.
it also explains why my own system years ago seemed more responsive
on the same hardware but i assumed that 9 was just doing much more
(which it was, of course, but that wasn't the cause).

a little off-topic but there's a similar problem in trying to
implement spin-locks in Linux and FreeBSD (using their respective
types of shared-memory processes).  the problem arises because there
seems to be no sensible locking scheme provided by the system.  (even
for implementing longer-term locks, after all these years, there seems
to be only that hopeless UNIX/TS semaphore stuff, or pipes.)

thus, we try to do spin-locks by hand using sched_yield() in the
process waiting for the lock.  there's obviously some churn as above,
but it would still be not too bad if only the processes remained at
the same priority.  if the process holding the lock happens to have earned a dynamic priority
less than the process waiting, it ends up churning away relinquishing
to every other process on its priority level (quite often only itself),
because sched_yield just puts it at the end of its current run queue.
using a fixed priority scheme would be not too bad, except
you seem to need to have a special module compiled in and
whether that's there or not, you apparently need to be super-user to use it.
having discovered this i'll probably just queue them myself but that apparently means
using the 'orrible Sys V locking crud.  better ideas on a e-postcard to me.

i mention it here rather than Linux groups because i hoped for a sensible answer,
but less unpleasantly because i have wondered whether /sys/src/libc/port/lock.c
could suffer a similar problem when the fixed priority option isn't set.