Re: 2.6.11-rc1-mm1

[Christoph Hellwig <hch@infradead.org>]

On Sun, Jan 16, 2005 at 03:11:00PM -0500, Robert Wisniewski wrote:
> int global_val;
> 
> modify_val_spin()
> {
> 	acquire_spin_lock()
> 	// calculate some_value based on global_val
> 	// for example c=global_val; if (c%0) some_value=10; else some_value=20;
> 	global_val = global_val + some_value
> 	release_spin_lock()
> }
> 
> modify_val_atomic()
> {
> 	do
> 	// calculate some_value based on global_val
> 	// for example c=global_val; if (c%0) some_value=10; else some_value=20;
> 	global_val = global_val + some_value
> 	while (compare_and_store(global_val, , ))
> }
> 
> What's the difference.  The deal is if two processes execute this code
> simultaneously and one gets interrupted in the middle of modify_val_spin,
> then the other wastes its entire quantum spinning for the lock.  In the
> modify_val_atomic if one process gets interrupted, no problem, the other
> process can proceed through, then when the first one runs again the CAS
> will fail, and it will go around the loop again.  Now imagine it was the
> kernel involved...

Just prevent that with spin_lock_irq.  But anyway this example doesn't
fit the ltt code.  cmpxchg loops can make lots of sense for such simple
loops, but as soon as you need to do significant work in the loop it
starts to get problematic.  Your example would btw be better off using
atomic_t and it's primitives so you abstract away the actual implementation
and the architecture can chose the most efficient implementation.