Messages in this thread | | | From | (Davide Libenzi) | Subject | Re: [patch] new spinlock variant, spinlock-2.3.30-A4 | Date | Wed, 1 Dec 1999 00:17:17 +0100 |
| |
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/
| |