atomic operation

  • Permalink
  • submit to reddit
  • Email
  • Follow


Hi,

 Is it official to say that fetching and storing a 'long' (for 32-bit
and 64-bit) is an atomic operation ?

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply guy 10/29/2004 2:33:59 PM

See related articles to this posting

"Guy" <guy.peleg@gmail.com> wrote in message
news:f4d01807.0410280800.4c62b16a@posting.google.com...

>  Is it official to say that fetching and storing a 'long' (for 32-bit
> and 64-bit) is an atomic operation ?

absolutely not.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Balog 10/31/2004 10:51:54 AM

guy.peleg@gmail.com (Guy) wrote in message 
news:<f4d01807.0410280800.4c62b16a@posting.google.com>...
> Hi,
> 
>  Is it official to say that fetching and storing a 'long' (for 32-bit
> and 64-bit) is an atomic operation ?
> 

No

joshua lehrer
factset research systems
NYSE:FDS

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply usenet_cpp 10/31/2004 10:54:22 AM

Guy wrote:
> Hi,
> 
>  Is it official to say that fetching and storing a 'long' (for 32-bit
> and 64-bit) is an atomic operation ?
>   peri
There's no C++ concept of atomic operations.   You'll have to
check your particular implementation for such support.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Ron 10/31/2004 10:54:43 AM

On 29 Oct 2004 10:33:59 -0400, guy.peleg@gmail.com (Guy) wrote in
comp.lang.c++.moderated:

> Hi,
> 
>  Is it official to say that fetching and storing a 'long' (for 32-bit
> and 64-bit) is an atomic operation ?

No, it is not.  Accesses of the type 'sig_atomic_t', defined in
<csignal> or <signal.h> are guaranteed to be atomic operations.  In
theory this could be an 8-bit type on 8-bit processors, but there
isn't much C++ activity on 8-bit processors these days.

In most cases it is signed or unsigned int, but there is no guarantee.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Jack 10/31/2004 11:16:03 AM

On 29 Oct 2004 10:33:59 -0400, Guy <guy.peleg@gmail.com> wrote:

>  Is it official to say that fetching and storing a 'long' (for 32-bit
> and 64-bit) is an atomic operation ?

I presume, you are talking atomic with regards to threads, right?

If so, then no, it's not. There are too many processor dependent factors  
involved.

On processors that work with aligned data only it's atomic only when  
reading and writing a machine word on machine instruction level, that is,  
the instruction is atomic and can't be interrupted in the middle. For 32  
bit processors the machine word is most likely also a 32-bit int. On  
processors which do work with unaligned data (like x86 does), it's only  
atomic when accessing properly aligned data.

But the machine instruction level atomicity buys you little in multithread  
code. The reason being memory visibility, that is, instruction atomicity  
does not imply that a written to memory value will immediately be seen by  
other threads on a multiprocessor, which is pretty much what you want.  
This is because all modern processors cache memory, writes go to cache,  
cache gets flushed to memory at arbitrary from code's point of view  
moments, other processors may know of the new value only when it has been  
written to memory. So, there must be a means to flush writes to memory and  
to signal other processors to update their cashes. This means are provided  
by memory barriers, that ensure that the effect of invoking them is that  
all other threads will see changes to memory made before invoking the  
memory barrier.

Operating systems provide memory barriers as function calls. For POSIX you  
can find a list of functions that issue the memory barrier here  
http://groups.google.com/groups?selm=opsf9kv0mjti5cme%40localhost.localdomain&rnum=2&filter=0.  
For win32 you may start looking here  
http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/synchro_88127404-a394-403f-a289-d61c45ab81d5.xml.asp


-- 
Maxim Yegorushkin

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Maxim 10/31/2004 11:18:33 AM

Maxim Yegorushkin wrote:
[...]
> Operating systems provide memory barriers as function calls. For POSIX you
> can find a list of functions that issue the memory barrier here
> 
http://groups.google.com/groups?selm=opsf9kv0mjti5cme%40localhost.localdomain&rnum=2&filter=0.

In addition to the links I've posted in my previous message, see
also <http://cmc.rice.edu/docs/docs/Adv1999Mar1RecentAdva.pdf>.

regards,
alexander.

P.S. DRB it totally wrong with respect to {non}conformance of
release consistency model, BTW.

--
"The current POSIX memory model is far from perfect. [...] I 
 really think you'd be far better off persuing this at the C++ 
 language level and lobbying for a language threading model that 
 can coexist with (carefully designed) POSIX implementations but 
 is not directly dependent on the POSIX language."

   -- DRB (sorta annoyed by pseudo-C++ illustrations ;-) )

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Alexander 11/2/2004 9:38:33 PM

Jack Klein wrote:
[...]
> >  Is it official to say that fetching and storing a 'long' (for 32-bit
> > and 64-bit) is an atomic operation ?
> 
> No, it is not.  Accesses of the type 'sig_atomic_t', defined in
> <csignal> or <signal.h> are guaranteed to be atomic operations.  

Only with respect to assignments in signal handlers (when this
or that signal is delivered to the same thread and only for static 
volatile sig_atomic_t objects). It has really nothing to do with 
threads (just in case you meant to imply that) Uhmm, see 
<http://tinyurl.com/5zvyj>. Better read this entire thread 
<http://tinyurl.com/5g6pm>... you might as well contribute. ;-)

regards,
alexander.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Alexander 11/2/2004 9:40:03 PM

Thanks but I think I need to rephrase the question. 

Suppose I have a 'long'(in either 32-bit or 64-bit) I have a process
with two threads. One is reading this 'long' and one is writing it. Is
it possible that while the writing thread is in the middle of the
writing, the process will switched to the reading thread? Or is it
true to say that this action (updating or reading) this long is safe?

Alexander Terekhov <terekhov@web.de> wrote in message news:<4187AF6B.E09C3A11@web.de>...
> Maxim Yegorushkin wrote:
> [...]
> > Operating systems provide memory barriers as function calls. For POSIX you
> > can find a list of functions that issue the memory barrier here
> > 
> http://groups.google.com/groups?selm=opsf9kv0mjti5cme%40localhost.localdomain&rnum=2&filter=0.
> 
> In addition to the links I've posted in my previous message, see
> also <http://cmc.rice.edu/docs/docs/Adv1999Mar1RecentAdva.pdf>.
> 
> regards,
> alexander.
> 
> P.S. DRB it totally wrong with respect to {non}conformance of
> release consistency model, BTW.
> 
> --
> "The current POSIX memory model is far from perfect. [...] I 
>  really think you'd be far better off persuing this at the C++ 
>  language level and lobbying for a language threading model that 
>  can coexist with (carefully designed) POSIX implementations but 
>  is not directly dependent on the POSIX language."
> 
>    -- DRB (sorta annoyed by pseudo-C++ illustrations ;-) )

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply guy 11/8/2004 11:36:46 PM

guy.peleg@gmail.com (Guy) wrote in message
news:<f4d01807.0411072321.719f19e2@posting.google.com>...

 > Thanks but I think I need to rephrase the question.

 > Suppose I have a 'long'(in either 32-bit or 64-bit) I have a process
 > with two threads. One is reading this 'long' and one is writing it. Is
 > it possible that while the writing thread is in the middle of the
 > writing, the process will switched to the reading thread? Or is it
 > true to say that this action (updating or reading) this long is safe?

It's not possible to say anything.

I think your missing what most of the posters have been trying to tell
you.  Atomicity is not necessarily relevant.  You speak of switching
threads, for example.  But on many machines today, there are two or more
threads running simultaneously -- no thread switch is necessary for
problems to occur, and the issue is not just atomicity, but visibility.
On most machines, a thread switch can only occur on an instruction
boundary -- Intel processors have an increment memory instruction, and
if thread switching on a single processor were the only issue, that
would suffice for an atomic increment.  It doesn't, and it is not
without reason that processors have additional hardware synchronization
means; even 25 years ago, Intel required a LOCK prefix on an increment
in memory, if you wanted the operation to be atomic, and the plethory of
caches and pipelines in a modern processor just makes the issue more
complex.

Under Posix, the rule is simple: if any thread modifies, all accesses
must be serialized by means of one of the system locking mechanisms
(mutex, semaphore, etc.).  I suspect that the rule under Windows is the
same.  On the other hand, many systems provide additional, system
specific methods of serialization or synchronization, and in most cases,
if you're not afraid of a little assembler, you can avoid the system
synchronizations in specific cases.  (On both Sparc and Intel 32 bit
architectures, this involves special machine instructions that are never
generated by the compiler.)

If all you mean is that if you have a long with 0, and one thread writes
0xFFFFFFFF, then other threads can never see anything but 0 or
0xFFFFFFFF (and not, for example, 0xFFFF0000 or 0x0000FFFF), then the
answer still depends on the processor and the alignement of the data.
And theoretically, at least, it is possible that the other thread never
see the change unless you do something special.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply kanze 11/9/2004 12:22:19 PM

guy.peleg@gmail.com (Guy) wrote in message news:<f4d01807.0411072321.719f19e2@posting.google.com>...
 > Thanks but I think I need to rephrase the question.
 >
 > Suppose I have a 'long'(in either 32-bit or 64-bit) I have a process
 > with two threads. One is reading this 'long' and one is writing it. Is
 > it possible that while the writing thread is in the middle of the
 > writing, the process will switched to the reading thread? Or is it
 > true to say that this action (updating or reading) this long is safe?

There are no guarantees in C++, whether longs are 32, 33 or 64 bits.
Of course, there are no threads in C++, so this usually doesn't
matter. Once you use a threading extension to C++, that extension
should tell you - and you should ask your question in a group which
covers that extension.

Regards,
Michiel Salters

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Michiel 11/9/2004 12:22:48 PM

Guy wrote:
 > Thanks but I think I need to rephrase the question.
 >
 > Suppose I have a 'long'(in either 32-bit or 64-bit) I have a process
 > with two threads. One is reading this 'long' and one is writing it. Is
 > it possible that while the writing thread is in the middle of the
 > writing, the process will switched to the reading thread? Or is it
 > true to say that this action (updating or reading) this long is safe?
<snip>

This is unanswerable without knowing the details of the running
environment (OS, processor architecture, library implementation...).
Multithreaded programs are outside the scope of the C++ standard.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply Ben 11/9/2004 12:27:01 PM

guy.peleg@gmail.com (Guy) wrote
> Thanks but I think I need to rephrase the question. 
> 
> Suppose I have a 'long'(in either 32-bit or 64-bit) I have a process
> with two threads. One is reading this 'long' and one is writing it. Is
> it possible that while the writing thread is in the middle of the
> writing, the process will switched to the reading thread? Or is it
> true to say that this action (updating or reading) this long is safe?

I don't think you've asked anything here that wasn't assumed the first
time around. In any case, the answer doesn't change: it's still NO.

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]
0
Reply allan_w 11/9/2004 9:11:44 PM
comp.lang.c++.moderated 10585 articles. 6 followers. Post

12 Replies
150 Views

Similar Articles

[PageSpeed] 9

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

Atomic variable Vs. Atomic operation
Hi, Lets say I have two shared variables a,b which are related to each other. When multiple applications share these shared variables, access to them needs to be an atomic operation, otherwise the relation may break. So to ensure mutual exclusion, I'll put their modification under a critical section protected by lock. critical_code { P(mutex) a := something b := something V(mutex) } Lets say my hardware/OS/compiler supports atomic variables. Then I modified my above code as follows. code { atomic a := something atomic b := something } Can this code ensure mutua...

Atomic variable Vs. Atomic operation
Hi, Lets say I have two shared variables a,b which are related to each other. When multiple applications share these shared variables, access to them needs to be an atomic operation, otherwise the relation may break. So to ensure mutual exclusion, I'll put their modification under a critical section protected by lock. critical_code { P(mutex) a := something b := something V(mutex) } Lets say my hardware/OS/compiler supports atomic variables. Then I modified my above code as follows. code { atomic a := something atomic b := something } ...

Atomic variable Vs. Atomic operation
Hi, Lets say I have two shared variables a,b which are related to each other. When multiple applications share these shared variables, access to them needs to be an atomic operation, otherwise the relation may break. So to ensure mutual exclusion, I'll put their modification under a critical section protected by lock. critical_code { P(mutex) a := something b := something V(mutex) } Lets say my hardware/OS/compiler supports atomic variables. Then I modified my above code as follows. code { atomic a := something atomic b := something } C...

Pseudo-atomic
http://semipublic.comp-arch.net/wiki/Pseudo-atomic [[Pseudo-atomic]] is a term that I (Glew) have coined to refer to atomic operations that can fail to be atomic, such as: * [[Load-linked/store-conditional (LL/SC)]] * IBM z196's [[LOAD PAIR DISJOINT]] * even [[hardware transactional memory]] ** such as [[Intel Transactional Synchronization Extensions (TSX)]]'s [[Restricted Transactional Memory (RTM)]], where "the [[XBEGIN]] instruction takes an operand that provides a relative offset to the fallback instruction address if the RTM region could not be successfully executed tra...

Atomic operations!!
Hi all I am porting an application from AIX to solaris, I just wanted to whether any equivalent APIs available on Solaris for these AIX routines such as, compare_and_swap(),_check_lock(),fetch_and_and () Thanks in advance, Seema Rao "seema" <seema_coma@yahoo.co.in> writes: >Hi all I am porting an application from AIX to solaris, I just wanted >to whether any equivalent APIs available on Solaris for these AIX >routines such as, > compare_and_swap(),_check_lock(),fetch_and_and () While compare_and_swap() is an obvious function, it would be nice if you told ...

Is this operation atomic?
I'm finishing up a total rewrite of an interrupt-heavy program (the previous version was a nightmare of pushf/cli/popf wrapping to prevent race conditions in code shared by multiple interrupt handlers -- don't ask) and I have been staring at it for so long that I am confusing myself as to which operations can be considered atomic or not. Here is clearing a flag variable (this is 16-bit real mode x86): C6060A0000 MOV BYTE PTR [000A],0 Can I consider this operation atomic, or can this somehow be interrupted once instruction decoding and execution has begun? Jim Leonard wro...

Atomic operations
Hi folks, what's the easiest way to call atomic operations like fetch-and-add and compare-and-swap with gcc on x86-64 Linux? Any (builtin) calls or intrinsics. I found some inline assembler macros, but they don't seem to work on 64-bit pointers: # define FETCH_AND_ADD(address,increment) \ asm volatile ( \ "lock xaddl %0,%1" \ : "=r" (increment), "=m" (address) \ : "0" (increment) : "memory"); There also is __gnu_cxx::__exchange_and_add(counter0_ptr, increment); but I'm not sure whether I'm "allowed" to cal...

Atomic Operation
I read sometime ago that there is new java feature to increment a long as atomic operation so threads can safely add one to the long. I cannot find name for such object, I think "AtomicLongIncrement" or something. Maybe someone can remember. I have been searching java doc, but cannot find it. dimitrik107@hotmail.com wrote: > I read sometime ago that there is new java feature to increment a long > as atomic operation so threads can safely add one to the long. I cannot > find name for such object, I think "AtomicLongIncrement" or something. > Maybe someone can ...

is ternary operator atomic?
Hello All, I have a question regarding the ternary operator usage in C and C++. If I write, ----------------- a = (a==9) ? 10 : 0; // a is an integer defined already ---------------------------------------- Is the ternary operator statement atomic across all platforms. By atomic, i mean can it be guaranteed that while this statement is being executed, context will not be switched between multiple threads in the same process space. Is there any such mention in the C/C++ standard, Or it is compiler dependent. Thanks, Saurabh Gupta On 01/07/2010 07:48, s...