definition of "atomic"

Nope, not home work

I'm still a newbie (forever), and I seen "atomic" mentioned in a few
threads recently
I've done a quick search on keil and wikipedia.

Anyone got a simple definition ( of atomic)?

Ta from 8051 land


martin

martin griffith wrote:

> Anyone got a simple definition ( of atomic)?

Succinctly: Indivisible.

Context-appositely: Uninterruptible.

You mostly run across this word when discussing multitasking issues.
For example, if you have a RAM counter in one thread (or ISR) and code
that reads that counter in a different thread (or ISR), you need an
atomic increment instruction to avoid the possibility that one thread
will update (or read) the counter while another thread is halfway
through updating, say, two bytes of it.

You also need atomic instructions to gate access to a resource. If you
have a flag that says "resource busy", it is necessary to have a single
instruction that will [effectively] set the flag, THEN conditional jump
based on the contents of the flag BEFORE the set operation. Otherwise,
a task could poll the flag, see the resource is free, then an interrupt
occurs and another task sees the resource is "still" free and takes it,
then the first task sets the busy flag (which was already set by the
second task) and both tasks now believe they own the resource.

Google "mutex atomic".

martin griffith wrote:
> Nope, not home work
>
> I'm still a newbie (forever), and I seen "atomic" mentioned in a few
> threads recently
> I've done a quick search on keil and wikipedia.
>
> Anyone got a simple definition ( of atomic)?
>
> Ta from 8051 land
>
>
> martin

An operation (usually, read-modify-write) that happens in one go and
cannot be interrupted.

A BITSET for example is usually atomic, since it is one instructions
and
cannot be interrupted.
compare that to reading a variable in to a register ORing the bit on
and
then storing the variable again. That is _not_ atomic because
an interrupt could get in between the intructions, potentially ending
up with
the wrong value in the register


-Lasse

On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
<> wrote:

>
>martin griffith wrote:
>
>> Anyone got a simple definition ( of atomic)?
>
>Succinctly: Indivisible.
>
>Context-appositely: Uninterruptible.
>
>You mostly run across this word when discussing multitasking issues.
>For example, if you have a RAM counter in one thread (or ISR) and code
>that reads that counter in a different thread (or ISR), you need an
>atomic increment instruction to avoid the possibility that one thread
>will update (or read) the counter while another thread is halfway
>through updating, say, two bytes of it.
>
>You also need atomic instructions to gate access to a resource. If you
>have a flag that says "resource busy", it is necessary to have a single
>instruction that will [effectively] set the flag, THEN conditional jump
>based on the contents of the flag BEFORE the set operation. Otherwise,
>a task could poll the flag, see the resource is free, then an interrupt
>occurs and another task sees the resource is "still" free and takes it,
>then the first task sets the busy flag (which was already set by the
>second task) and both tasks now believe they own the resource.
>
>Google "mutex atomic".
Thanks for that, I gathered that it was indivisble, but I couldn't
figure out what was being divided !

Now I'll go back and re-read the threads :-)


martin

On Fri, 15 Sep 2006 23:31:05 +0200, martin griffith
<> wrote:

>On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
><> wrote:
>
>>
>>martin griffith wrote:
>>
>>> Anyone got a simple definition ( of atomic)?
>>
>>Succinctly: Indivisible.
>>
>>Context-appositely: Uninterruptible.
>>
>>You mostly run across this word when discussing multitasking issues.
>>For example, if you have a RAM counter in one thread (or ISR) and code
>>that reads that counter in a different thread (or ISR), you need an
>>atomic increment instruction to avoid the possibility that one thread
>>will update (or read) the counter while another thread is halfway
>>through updating, say, two bytes of it.
>>
>>You also need atomic instructions to gate access to a resource. If you
>>have a flag that says "resource busy", it is necessary to have a single
>>instruction that will [effectively] set the flag, THEN conditional jump
>>based on the contents of the flag BEFORE the set operation. Otherwise,
>>a task could poll the flag, see the resource is free, then an interrupt
>>occurs and another task sees the resource is "still" free and takes it,
>>then the first task sets the busy flag (which was already set by the
>>second task) and both tasks now believe they own the resource.
>>
>>Google "mutex atomic".
>Thanks for that, I gathered that it was indivisble, but I couldn't
>figure out what was being divided !
>
>Now I'll go back and re-read the threads :-)

Ah, but do you know the "simple definition" of a thread??

Jon

wrote:
> martin griffith wrote:
>
>> Nope, not home work
>>
>> I'm still a newbie (forever), and I seen "atomic" mentioned in a few
>> threads recently
>> I've done a quick search on keil and wikipedia.
>>
>> Anyone got a simple definition ( of atomic)?
>
> An operation (usually, read-modify-write) that happens in one go and
> cannot be interrupted.
>
> A BITSET for example is usually atomic, since it is one instructions
> and cannot be interrupted.
> compare that to reading a variable in to a register ORing the bit on
> and then storing the variable again. That is _not_ atomic because
> an interrupt could get in between the intructions, potentially ending
> up with the wrong value in the register

However, on a uniprocessor system, such an operation can be made
atomic by disabling interrupts, doing the read/set/write, and then
re-enabling interrupts. This fails on a multi-processor system.
It helps if the act of disabling interrupts returns the actual
interrupt state, which can then be restored after the operation.
Then you don't have to know that interrupts were enabled before
beginning.

oldstate = disable();
/* operations to be made atomic */
enable(oldstate);

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

On Fri, 15 Sep 2006 21:34:51 GMT, in comp.arch.embedded Jonathan
Kirwan <> wrote:

>On Fri, 15 Sep 2006 23:31:05 +0200, martin griffith
><> wrote:
>
>>On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
>><> wrote:
>>
>>>
>>>martin griffith wrote:
>>>
>>>> Anyone got a simple definition ( of atomic)?
>>>
>>>Succinctly: Indivisible.
>>>
>>>Context-appositely: Uninterruptible.
>>>
>>>You mostly run across this word when discussing multitasking issues.
>>>For example, if you have a RAM counter in one thread (or ISR) and code
>>>that reads that counter in a different thread (or ISR), you need an
>>>atomic increment instruction to avoid the possibility that one thread
>>>will update (or read) the counter while another thread is halfway
>>>through updating, say, two bytes of it.
>>>
>>>You also need atomic instructions to gate access to a resource. If you
>>>have a flag that says "resource busy", it is necessary to have a single
>>>instruction that will [effectively] set the flag, THEN conditional jump
>>>based on the contents of the flag BEFORE the set operation. Otherwise,
>>>a task could poll the flag, see the resource is free, then an interrupt
>>>occurs and another task sees the resource is "still" free and takes it,
>>>then the first task sets the busy flag (which was already set by the
>>>second task) and both tasks now believe they own the resource.
>>>
>>>Google "mutex atomic".
>>Thanks for that, I gathered that it was indivisble, but I couldn't
>>figure out what was being divided !
>>
>>Now I'll go back and re-read the threads :-)
>
>Ah, but do you know the "simple definition" of a thread??
>
>Jon
well, since you ask :
1) used to hold the cute patches on my jeans, in the 80's
2) something to do with the missapplication of terrorism?
3) no


martin

On 15 Sep 2006 14:27:38 -0700, in comp.arch.embedded
wrote:

>
>martin griffith wrote:
>> Nope, not home work
>>
>> I'm still a newbie (forever), and I seen "atomic" mentioned in a few
>> threads recently
>> I've done a quick search on keil and wikipedia.
>>
>> Anyone got a simple definition ( of atomic)?
>>
>> Ta from 8051 land
>>
>>
>> martin
>
>An operation (usually, read-modify-write) that happens in one go and
>cannot be interrupted.
>
>A BITSET for example is usually atomic, since it is one instructions
>and
>cannot be interrupted.
>compare that to reading a variable in to a register ORing the bit on
>and
>then storing the variable again. That is _not_ atomic because
>an interrupt could get in between the intructions, potentially ending
>up with
>the wrong value in the register
>
>
>-Lasse
Love this newsgroup, thanks


martin

CBFalconer wrote:
> wrote:
> > martin griffith wrote:
> >
> >> Nope, not home work
> >>
> >> I'm still a newbie (forever), and I seen "atomic" mentioned in a few
> >> threads recently
> >> I've done a quick search on keil and wikipedia.
> >>
> >> Anyone got a simple definition ( of atomic)?
> >
> > An operation (usually, read-modify-write) that happens in one go and
> > cannot be interrupted.
> >
> > A BITSET for example is usually atomic, since it is one instructions
> > and cannot be interrupted.
> > compare that to reading a variable in to a register ORing the bit on
> > and then storing the variable again. That is _not_ atomic because
> > an interrupt could get in between the intructions, potentially ending
> > up with the wrong value in the register
>
> However, on a uniprocessor system, such an operation can be made
> atomic by disabling interrupts, doing the read/set/write, and then
> re-enabling interrupts. This fails on a multi-processor system.
> It helps if the act of disabling interrupts returns the actual
> interrupt state, which can then be restored after the operation.
> Then you don't have to know that interrupts were enabled before
> beginning.
>
> oldstate = disable();
> /* operations to be made atomic */
> enable(oldstate);
>

yep, an ARM7 has a swap instruction, and I've seen PPCs with a way
to "lock" a memory area to see if a if it was touched between
instructions

both ways means you'd have to retry the operation untill you know it
was safe,
so usually peripheral registers such as an interrupt mask have a
bitset/bitclear address
when it is not supported by instructions

-Lasse

larwe wrote:
> martin griffith wrote:
>
>> Anyone got a simple definition ( of atomic)?
>
> Succinctly: Indivisible.
>
> Context-appositely: Uninterruptible.

Actually, "atomic" means "no intermediate results are visible".
The trivial way of doing this is by disabling interrupts.
There are other approaches *including* "interruptible"
implementations.