1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

definition of "atomic"

Discussion in 'Embedded' started by martin griffith, Sep 15, 2006.

  1. 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, Sep 15, 2006
    #1
    1. Advertising

  2. martin griffith

    larwe Guest

    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".
     
    larwe, Sep 15, 2006
    #2
    1. Advertising

  3. martin griffith

    Guest

    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
     
    , Sep 15, 2006
    #3
  4. 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
     
    martin griffith, Sep 15, 2006
    #4
  5. 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
     
    Jonathan Kirwan, Sep 15, 2006
    #5
  6. martin griffith

    CBFalconer Guest

    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
     
    CBFalconer, Sep 15, 2006
    #6
  7. 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
     
    martin griffith, Sep 15, 2006
    #7
  8. 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
     
    martin griffith, Sep 15, 2006
    #8
  9. martin griffith

    Guest

    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
     
    , Sep 16, 2006
    #9
  10. martin griffith

    Don Guest

    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.
     
    Don, Sep 16, 2006
    #10
  11. martin griffith

    BobG Guest

    There's gotta be a pun about nu-que-ler or nuclear here somewhere
     
    BobG, Sep 16, 2006
    #11
  12. martin griffith

    Neil Guest

    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


    Simply the instruction can not be divided.

    For a specify CPU (especially the 8051) it is a single machine code
    instruction. The current instruction will always finish before the CPU
    will vector to a interrupt. This makes them atomic.

    So for the 8051 certain increments, assigns, and bit instructions are
    atomic. A 16 bit add can not be. While on a Pentium it would.
     
    Neil, Sep 16, 2006
    #12
  13. On Sat, 16 Sep 2006 04:36:30 GMT, Neil <>
    wrote:

    >So for the 8051 certain increments, assigns, and bit instructions are
    >atomic. A 16 bit add can not be. While on a Pentium it would.


    The problem with architectures supporting virtual memory is that the
    page fault interrupt can occur within an instruction at every memory
    access and the page fault routine must load the missing page from disk
    etc. which can take a considerable time.

    Thus special lock prefixes or special interlocked instructions are
    required on virtual memory machines. Even if the processor supports
    unaligned word/dword access, the interlocking variable must usually be
    placed at a natural alignment, i.e. the variable can not cross page
    boundaries, in order to prevent the page fault within the variable
    access.

    Paul
     
    Paul Keinanen, Sep 16, 2006
    #13
  14. Don wrote:
    > 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.
    >

    This is only valid for a uniprocessor.
    If there are >1 processor (that term includes DMAs, smart IO
    coprocessors, etc) you must ensure they cannot break in either.
    Hopefully the CPU includes explicitly atomic instructions, which will
    lock the memory bus during the read/modify/write sequence.
     
    David R Brooks, Sep 16, 2006
    #14
  15. martin griffith

    Don Guest

    David R Brooks wrote:
    > Don wrote:
    >> 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.
    >>

    > This is only valid for a uniprocessor.
    > If there are >1 processor (that term includes DMAs, smart IO
    > coprocessors, etc) you must ensure they cannot break in either.
    > Hopefully the CPU includes explicitly atomic instructions, which will
    > lock the memory bus during the read/modify/write sequence.


    You're thinking at too "specific" a level of detail.
    All you have to do is ensure "no intermediate results are
    visible". Whether you are dealing with maintaining a
    counter or synchronizing access to a RDBMS (Shirley you
    don't think RDBMS's use simple locks to get atomic actions?)

    Think outside the box and stop thinking about the processor's
    *hardware*.
     
    Don, Sep 17, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Son Of Sheep.
    Replies:
    2
    Views:
    423
  2. No One Realy
    Replies:
    9
    Views:
    343
    Brian Brunner
    Sep 20, 2005
  3. John
    Replies:
    7
    Views:
    669
  4. leilei

    atomic operation problem

    leilei, Dec 1, 2008, in forum: Embedded
    Replies:
    11
    Views:
    332
    Coos Haak
    Dec 4, 2008
  5. alb
    Replies:
    29
    Views:
    550
Loading...

Share This Page