[lkml]   [2002]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] New locking primitive for 2.5
Robert Love wrote:

> Some of the talk I've heard has been toward an adaptive lock. These
> are locks like Solaris's that can spin or sleep, usually depending on
> the state of the lock's holder. Another alternative, which I prefer
> since it is much less overhead, is a lock that spins-then-sleeps
> unconditionally.

Dave Hanson wrote:

> he spin-then-sleep lock could be interesting as a replacement for the
> BKL in places where a semaphore causes performance degredation. In
> quite a few places where we replaced the BKL with a more finely grained
> semapore (not a spinlock because we needed to sleep during the hold),
> instead of spinning for a bit, it would schedule instead. This was bad
> :). Spin-then-sleep would be great behaviour in this situation.

Wouldn't it be sufficient to include the following patch of code
at the beginning of __combi_wait(...):

if (smp_processor_id() != owner->cpu) {
int cnt=MAX_LOOP_CNT;
do {
while (--cnt && x->owner);
if (!x->owner)
if (cnt)
goto retry;
then the sleep code of __combi_wait(...)

If one fears that the owner (or current if the kernel is made
preemptible) migrated to the same cpu while we are spinning
for x->owner and hence may
make no progress, one could let the waiting loop last about a typical
process switch time and add an outer loop that checks if the cpu
of the owner is still different.

Martin Wirth
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.200 / U:2.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site