CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 8 of 8
  1. #1
    Join Date
    Dec 2014
    Posts
    13

    Java "volatile" alternative in C++ under Windows?

    I know from Java that having two threads sharing a global variable can cause two problems:
    1) Each thread can "cache" its own copy of the variable and manipulate this copy from now on.
    2) When editing the global variable at the same time by both threads this can result in unexpected results.

    I can solve the second problem using critical sections in WinAPI but first problem is what I don't know how to solve.

    Note: I know that in C++ there is a "volatile" keyword but as I understand it has a different meaning than that of Java.

  2. #2
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Java "volatile" alternative in C++ under Windows?

    Critical sections, and all Win32 synchronization primitives, solve 1 and 2.

    gg

  3. #3
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,582

    Re: Java "volatile" alternative in C++ under Windows?

    volatile in c++ is a hint to the compiler that the value of the variable may change in a way that the compiler may not anticipate and so when the value of the variable is required any value already held in registers etc shouldn't be used but the value should be obtained directly from the memory for which it is allocated.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++20 Compiler: Microsoft VS2022 (17.0.5)

  4. #4
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Java "volatile" alternative in C++ under Windows?

    Quote Originally Posted by Codeplug View Post
    Critical sections, and all Win32 synchronization primitives, solve 1 and 2.
    No they don't. or tather, the sync primitives don't do this in and by themselves.

    Rather, the C++ language definition will take care of creating a read/write gate because it needs to "resolve all side effects" before doing the call into the sync primitive.
    And likewise the CPU will do the same around a call so it'll clear the CPU pipeline before doing the call and before doing the return (or at least achieve that effect).


    volatile as 2kaud said is a compiler hint. DO not make assumptions about what a compiler will do with this, it is perfectly valid for a compiler to totally ignore the volatile entirely (and some do).
    Your compiler manual will typically point out what volatile does in that specific compiler and if you so desire, you can make non-portable assumptions in your code based around those compiler specifics.
    If you need portability, use the stuff in the <atomic> header

  5. #5
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Java "volatile" alternative in C++ under Windows?

    >> No they don't. or rather, the sync primitives don't do this in and by themselves.
    "Pull over, pull over - semantics police!"
    So they don't solve 1 and 2 in and by themselves, but by them being there, they solve 1 and 2.

    I want to recall from a Herb Sutter talk on Prism that the compiler is actually a little bit smarter than "read/write gate here due to external call that I don't have the source to". Of course its a lot more complex than that

    >> volatile as 2kaud said is a compiler hint. DO not make assumptions about what a compiler will do with this, it is perfectly valid for a compiler to totally ignore the volatile entirely (and some do).
    "inline" is hint - volatile is not. Any compiler that completely ignores it isn't a standard implementation. Some compilers have added semantics to the volatile keyword that go beyond what the standard specifies - the manual is indeed your friend here.

    gg

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Java "volatile" alternative in C++ under Windows?

    Quote Originally Posted by Codeplug View Post
    >> No they don't. or rather, the sync primitives don't do this in and by themselves.
    "Pull over, pull over - semantics police!"
    So they don't solve 1 and 2 in and by themselves, but by them being there, they solve 1 and 2.
    It goes a bit beyond just semantics. ANY function call will cause a gating except when the compiler "knows" the function can't touch the variable.


    I want to recall from a Herb Sutter talk on Prism that the compiler is actually a little bit smarter than "read/write gate here due to external call that I don't have the source to". Of course its a lot more complex than that
    Yes, it is.

    "inline" is hint - volatile is not. Any compiler that completely ignores it isn't a standard implementation. Some compilers have added semantics to the volatile keyword that go beyond what the standard specifies - the manual is indeed your friend here.
    And for C++11 the manual very clearly states volatile is for hardware access only (interrupts on the same thread) and not to be used for multithreading, you should use the <atomic> stuff for multithreading access.
    I don't have the book handy to point out the actual section. Any online references somewhere ?

    So volatile does not require a compliant compiler to force rereads/writes (=gating) at every point. It is acceptable for the compiler to disable interrupts temporarily perform a lengthy bit of code with a volatile in a register, and update the memory only just before enabling interrupts again. I have compilers that behave exactly like that and they are (or at least claim to be C++ compliant), I've never went to the trouble of actually testing them for every compliance item.

  7. #7
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,582

    Re: Java "volatile" alternative in C++ under Windows?

    I don't have the book handy to point out the actual section. Any online references somewhere ?
    This gives the Jan 2012 draft version of c++14 (free!)
    http://www.open-std.org/jtc1/sc22/wg...2012/n3337.pdf
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++20 Compiler: Microsoft VS2022 (17.0.5)

  8. #8
    Join Date
    Nov 2003
    Posts
    1,902

    Re: Java "volatile" alternative in C++ under Windows?

    >> And for C++11 the manual very clearly states volatile is for hardware access only (interrupts on the same thread) and not to be used for multithreading, you should use the <atomic> stuff for multithreading access.
    Agreed.

    >> So volatile does not require a compliant compiler to force rereads/writes (=gating) at every point.
    Agreed.

    When I say volatile isn't a hint, I mean that conforming implementations should do what 2kaud described in post #3. In addition to emitting real memory accesses, the compiler can not reorder volatile accesses with respect to each other.

    Here's an old quote from N3092 on a similar topic: http://cboard.cprogramming.com/c-pro...tml#post964990

    gg

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured