Re: how atomic is the atomic set instruction?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
[Linux ARM] [Linux ARM MSM] [Linux ARM Kernel] [Fedora ARM] [IETF Annouce] [Security] [Bugtraq] [Linux] [Linux OMAP] [Linux MIPS] [ECOS] [Asterisk Internet PBX] [Linux API]