--- /n/sources/plan9/sys/man/2/lock Mon Oct 5 23:14:32 2009 +++ /sys/man/2/lock Wed Aug 3 00:00:00 2016 @@ -282,26 +282,20 @@ .SH SEE ALSO .I rfork in -.IR fork (2) +.IR fork (2), +.IR semacquire (2) .SH BUGS .B Locks -are not strictly spin locks. -After each unsuccessful attempt, +are not actually spin locks. +After one unsuccessful attempt, .I lock calls -.B sleep(0) -to yield the CPU; this handles the common case -where some other process holds the lock. -After a thousand unsuccessful attempts, -.I lock -sleeps for 100ms between attempts. -After another thousand unsuccessful attempts, -.I lock -sleeps for a full second between attempts. +.I semacquire +repeatedly (thus yielding the CPU) +until it succeeds in acquiring a semaphore internal to the +.BR Lock . .B Locks are not intended to be held for long periods of time. -The 100ms and full second sleeps are only heuristics to -avoid tying up the CPU when a process deadlocks. As discussed above, if a lock is to be held for much more than a few instructions, the queueing lock types should be almost always be used.