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! ]

"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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]

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! ]