Re: how atomic is the atomic set instruction?

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Sat, Nov 08, 2008 at 10:05:16PM -0600, Bill Gatliff wrote:
> Russell King - ARM Linux wrote:
> > On Sat, Nov 08, 2008 at 03:59:50PM +0100, Ali Günhan Akyürek wrote:
> >> atomic_set doesn´t say anything about interrupts. So i assume interrupts
> >> are on, and context switch can occur. Between the load and store
> >> instruction.
> > 
> > As I've told you before, just because something's called "atomic" doesn't
> > make it atomic.  Your use is plan and simple buggy.
> 
> You guys aren't talking about the same "atomic".
> 
> The atomic_* operations manipulate the atomic_t data type in ways that
> guarantee that the value cannot get munged even if a competing thread
> attempts an update at the same time.

Actually, that's not correct.  As I've already said:

	val = atomic_read(&foo);
	manipulate val
	atomic_set(val, &foo);

is _not_ atomic, and never will be.  Just because something's called
"atomic" does not make it overall atomic.

The only operations on atomic_t which _are_ atomic are:

	atomic_add_return
	atomic_sub_return
	atomic_cmpxchg
	atomic_clear_mask
	atomic_add_unless
	atomic_inc_not_zero
	atomic_add
	atomic_inc
	atomic_sub
	atomic_dec
	atomic_inc_and_test
	atomic_dec_and_test
	atomic_inc_return
	atomic_dec_return
	atomic_sub_and_test
	atomic_add_negative

> BUT, the sequence of instructions needed to implement the atomic_t
> type do not necessarily have to be uninterruptible, and indeed on ARM
> they are not.
> 
> Case in point: in the OP's example, the location of 'i' isn't changing
> and so it doesn't matter how long it takes to calculate the address,
> or whether an interruption occurs during that calculation or not.  All
> that's important is that when you finally have the address and value
> in question, you can commit the value to its destination (register or
> memory) in a single transaction.

No.  The "store to memory" operation is always atomic if it can be only
viewed from elsewhere in the system as being either not committed or
fully committed.  That is generally the case with ARMs 'STR' instruction.

But... why use atomic_set() just to store a value?  Wouldn't using a
standard pointer be sufficient?  It'll generate the same code.

And that's my point - if you're trying to use atomic_set() to make
something "atomic" then you're being silly.  atomic_set() is just a
plain CPU store - it has no overall guaranteed atomicity apart from
the fact that it'll issue a store.

It doesn't make the surrounding operations somehow magically atomic.

So, the original question asking about "how atomic atomic_set is"
rings very loud alarm bells to me, bringing up big concerns about
what the OP wants to do.  If you need to know how atomic atomic_set
is, you ARE doing something wrong.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php