Thread: Atomicity is confusin me

  1. #1
    Registered User
    Join Date
    Dec 2011
    Posts
    5

    Question Atomicity is confusin me

    Dear all,

    I am totally confused about atomicity. Probably some of you are more familiar with this topic.

    What I wanted to know is, if e.g. this is thread safe or not:
    Code:
    do {
       long save_state = long_long_global;
       \\ do s.th., update save_state to new_save_state
    }while(!atomic_compare_and_swap(&long_long_global, save_state, new_save_state);
    Do I need to declare long_long_global (64bit long int on a 64bit machine) as volatile? If so, why? Does it depend on the language? E.g. Java, C++? Is reading of a 64bit pointer or a long on a 64bit machine atomic? Does it depend on alignment (fields in classes are explicatively not aligned?). Do I need to read atomically, if I know that all write access is atomic? And if there are other problems, please report.

    Thanks a lot,
    Cheers

  2. #2
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Atomic operations depend much on hardware, I think, and as such are probably not very portable. They are thread safe by definition and are used to implement semaphores and mutexes. Ie, the better practice is to use the portable semaphores and/or mutexes that are part of your threading API, and leave the system specific stuff up to the implementation.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #3
    Registered User
    Join Date
    Dec 2011
    Posts
    5
    I have no choice. I do need to optimize performance. It's just for my thesis. So I can go slightly into details and it must not be used in production. Nevertheless, the upcoming C++ standard defined a std::atomic api. It's then up to the compiler to utilize the hardware capabilities. I am not scared about portability. Even though a cas command should be available on most recent hardware. But I am scared, that even if the long_long_global needs to be volatile, that reading would not be atomic.

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Sanches View Post
    Even though a cas command should be available on most recent hardware.

    But I am scared, that even if the long_long_global needs to be volatile, that reading would not be atomic.
    I guess whether you can really use a long long atomically depends on the actual cas API you use. Eg:

    from Atomic Builtins - Using the GNU Compiler Collection (GCC)
    The definition given in the Intel documentation allows only for the use of the types int, long, long long as well as their unsigned counterparts. GCC will allow any integral scalar or pointer type that is 1, 2, 4 or 8 bytes in length.
    I was (sort of) wrong about portability -- gcc implements this based on an intel specification but guarantees the implementation regardless of the hardware (or so it looks to me). You also might want to look at this:

    boost/interprocess/detail/atomic.hpp - Boost 1.43.0

    That one uses the keyword "volatile", however, that is bound into a larger threading library with various custom types. In general, it sounds like volatile is not necessarily desirable:

    g++ - Atomic swap in GNU C++ - Stack Overflow

    and qv. the article linked in there regarding the use of volatile in C/C++:

    volatile vs. volatile | Dr Dobb's

    By my reading, volatile is actually unnecessary overkill. C++0x std::atomic is mentioned.
    Last edited by MK27; 12-08-2011 at 08:50 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by MK27 View Post
    Atomic operations depend much on hardware, I think, and as such are probably not very portable. They are thread safe by definition and are used to implement semaphores and mutexes. Ie, the better practice is to use the portable semaphores and/or mutexes that are part of your threading API, and leave the system specific stuff up to the implementation.
    Atomic operations should be the default strategy, only falling back to performance-killing synchronization objects when their use is impossible. Synchronization will ruin scalability every time.

    To the OP: if you are worried that the operation is not really atomic, disassemble the code and look. As for whether volatile is required, the rule is, if you are unsure then don't use it. For straight multithread code written properly, it is never necessary.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> Do I need to declare long_long_global (64bit long int on a 64bit machine) as volatile?
    No. The function "atomic_compare_and_swap()" should just do a CAS on the given memory location.

    gg

  7. #7
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    I find it strange that GCC guarantees atomic long long operations even on 32-bit machines. That must incur huge performance penalty.

    Are you sure it's not Itanium-specific? The page refers to the Itanium ABI, and Itanium is 64-bit.

  8. #8
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by cyberfish View Post
    Are you sure it's not Itanium-specific? The page refers to the Itanium ABI, and Itanium is 64-bit.
    Sure as in I have tested the premise? No.

    However, (if you go up a link), it is the "Atomic Builtins" section of the "C extensions" part of the gcc 4.1 docs. I just found it via google and was trying to flush more birds from the bush * but that implies to me it is a built-in and while it does say:

    The following builtins are intended to be compatible with those described in the Intel Itanium Processor-specific Application Binary Interface, section 7.4.
    It does not say they are for use only on Intel compatible 64-bit processors. I imagine a quick post to some mailing list could confirm this one way or another.

    * so I dunno about the OP, but I learned some stuff about atomicity in this thread, lol
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  9. #9
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    They are not Itanium specific. I've used them on x86-32 and x86-64 (but not Itanium).

    gg

  10. #10
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    There's Boost.Atomic, an implementation of the standard atomics. It's not yet in Boost itself (should be soon, though), but you can find the implementation in a zip somewhere. It should take these issues off your shoulders.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Tags for this Thread