On 5 Jul 2002, Momchil Velikov wrote: > Michael> of what exactly spin_lock() is doing. Below is how I understand > Michael> spin_lock() to be expanded and what that means in context. This > Michael> is looking at the x86 spinlock in 2.4.19-rc1. For those with a > Michael> better understanding of this, I'd like to ask: > > Michael> 2 - why the use of 'rep ; nop' in the spin? > > In the dark ages, where there were no caches (worth talking about), it > was considered fair to release the bus before the bus arbiter gives > bus ownership to some other CPU, so other CPUs are given a chance to > run (and release the lock). > > Nowdays, I'm wandering too ... Thanks for that information... I hadn't even considered something like that. As for nowadays, apparently there's a need for it. I was curious so tightened up the spin on a test kernel and while it booted and ran, a number of daemons wound up thrashing about before a hasty SIGSEGV. Now I just need to find the time to figure out why. > Besides, it is IMHO another fine example of broken code, "rep; nop" > modifies (e)cx, but the insn clobbers do not mention it. Sigh, guess > it is easier to blame the compiler ... I wasn't too worried about 'rep' trashing ecx. If the caller needs ecx as a local loop counter that badly, then odds are we have a tight loop inside a tight loop. Our potential problems at that point are larger than what's in ecx. > The ``decb'' insn is a read-modify-write operation, which on a MP > system is not guaranteed to be atomic without the lock prefix. Understood... so it prevents the situation where we read, then before we write the modified value back to memory, another process reads the old value. If foo->lock were 1 on our entry then both of us would fall through the spin and think we have an exclusive lock. > Michael> # spin_unlock_string > Michael> # why not 'lock' instruction here? > Michael> movb $1, lock.lock # lock->lock = 1; release our lock > > 4-byte writes on 4-byte aligned addresses are atomic. So much more to learn. Thank you for taking the time to reply. The information you provided is most helpful. Mike -- Michael Janicki Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x9D6FAE1A Fingerprint: A153 DFC7 8B49 7E97 67B2 3DCE DA3F 3CC5 9D6F AE1A -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
