Christoph Hellwig writes:
> 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
The loop in question is where we grab the current (old) index, perform a
computation (or three). The only expensive operation is the timestamp
acquisition which has been modified to use the cheaper rtsc, so I still
think that's within the realm of a reasonably simply loop. I think what
you want to avoid is starting to walk a (potentially indeterminate) data
structure in such atomic op loop.
> atomic_t and it's primitives so you abstract away the actual implementation
> and the architecture can chose the most efficient implementation.
>
That's an interesting thought because it might address Andrew's concern.
We'll investigate. Thanks.
-bob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
