Motherboard Forums


Reply
Thread Tools Display Modes

definition of "atomic"

 
 
martin griffith
Guest
Posts: n/a
 
      09-15-2006, 08:41 PM
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
 
Reply With Quote
 
 
 
 
larwe
Guest
Posts: n/a
 
      09-15-2006, 09:15 PM

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".

 
Reply With Quote
 
 
 
 
langwadt@ieee.org
Guest
Posts: n/a
 
      09-15-2006, 09:27 PM

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

 
Reply With Quote
 
martin griffith
Guest
Posts: n/a
 
      09-15-2006, 09:31 PM
On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
<(E-Mail Removed)> 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
 
Reply With Quote
 
Jonathan Kirwan
Guest
Posts: n/a
 
      09-15-2006, 09:34 PM
On Fri, 15 Sep 2006 23:31:05 +0200, martin griffith
<(E-Mail Removed)> wrote:

>On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
><(E-Mail Removed)> 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
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-15-2006, 09:55 PM
(E-Mail Removed) 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

 
Reply With Quote
 
martin griffith
Guest
Posts: n/a
 
      09-15-2006, 09:56 PM
On Fri, 15 Sep 2006 21:34:51 GMT, in comp.arch.embedded Jonathan
Kirwan <(E-Mail Removed)> wrote:

>On Fri, 15 Sep 2006 23:31:05 +0200, martin griffith
><(E-Mail Removed)> wrote:
>
>>On 15 Sep 2006 14:15:09 -0700, in comp.arch.embedded "larwe"
>><(E-Mail Removed)> 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
 
Reply With Quote
 
martin griffith
Guest
Posts: n/a
 
      09-15-2006, 10:01 PM
On 15 Sep 2006 14:27:38 -0700, in comp.arch.embedded (E-Mail Removed)
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
 
Reply With Quote
 
langwadt@ieee.org
Guest
Posts: n/a
 
      09-16-2006, 01:16 AM

CBFalconer wrote:
> (E-Mail Removed) 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

 
Reply With Quote
 
Don
Guest
Posts: n/a
 
      09-16-2006, 02:48 AM
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SBLive 5.1 PCI or P5WD2 builtin Realtek ALC882D High Definition Audio 8-channel CODEC John Asus 7 09-27-2005 02:11 PM
AMD 3800 X2 Dual core good for High Definition Video Encoding if so how good ?? No One Realy Abit 9 09-20-2005 09:31 PM
AMD Barton VS Amd 64 Bit for High Definition Video how much better is a AMD 64 CPU ?? Son Of Sheep. Abit 2 07-14-2005 09:16 PM
Unusual Virus Definition Update Activity TR Gateway 3 02-26-2005 03:46 AM
Gigabyte - High Definition Video Playback at Value Prices - GV-NX62128D Gigabyte USA Marketing Gigabyte 0 11-23-2004 10:24 PM


All times are GMT. The time now is 09:53 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment