lkml.org 
[lkml]   [1999]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] new spinlock variant, spinlock-2.3.30-A4
Date
Tuesday, November 30, 1999 11:08 PM
Bret Indrelee <bindrelee@sbs-cp.com> wrote :

> Actually, I figured he was taking this from a fairly well known lock-free
> method. The problems with the normal method in the general case are:
> 1. It can livelock. The more the lock is contended for, the more likely
this
> is.
> 2. Data size of the lock grows linearly with number of contenders (CPUs in
> this case).
> 3. Time required to scan grows linearly with number of contenders.
>
> I believe he is only suggesting it be used to check if there was
contention,
> if it fails you fall back to the locked transactions. That may remove the
> problem with livelock.

I agree with Bret here.
I can see the Mingo code only a fast entry lockless test , ex :

For CPU3

movb $1, 3(%%esi)
movl 4(%%esi), %%edx
addl (%%esi), %%edx
cmpl $0x01000000, %%edx
je lock_acquired
lock_loop:
lock;
....
j?? lock_acquired
jmp lock_loop
lock_acquired:


Cheers,
Davide.

--
"Debian, the Freedom in Freedom."



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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