> 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/