dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 3 of 3

Thread: OK to write to pointer returned with consume semantics?

  1. #1
    Join Date
    Mar 2006
    Posts
    149

    OK to write to pointer returned with consume semantics?

    Hello:

    I think the typical usage pattern for using std::memory_order_consume is something like this:

    Code:
    std::atomic<int> state;
    ...
    int x = state.load(std::memory_order_consume);
    int y = x * slope; // correct because y depends on x
    Would the following still be correct?

    Code:
    std::atomic<int *> state;
    ...
    int * px = state.load(std::memory_order_consume);
    *px = y / slope; // Does this break the dependency?
    On one hand, I'd think this would be guaranteed to work because the memory being dereferenced to write the pointer "depends" on the pointer value, but on the other hand, it looks fishy to me and leaves me with some lingering doubts.

    Thanks for any insight,
    GeoRanger

  2. #2
    Join Date
    Nov 2003
    Location
    Belgium
    Posts
    8,115

    Re: OK to write to pointer returned with consume semantics?

    Specifying your own memory ordering is very advanced stuff.
    Herb Sutter has a very nice two-part presentation on this: https://channel9.msdn.com/Shows/Goin...Weapons-1-of-2
    Part one describes the C++ memory model.
    Also, I would recommend not to play with memory ordering, unless you know exactly what you are doing. Usually, for most situations, using the default memory ordering is advised.
    Marc Gregoire - NuonSoft (http://www.nuonsoft.com)
    My Blog
    Wallpaper Cycler 3.5.0.97

    Author of Professional C++, 4th Edition by Wiley/Wrox (includes C++17 features)
    ISBN: 978-1-119-42130-6
    [ http://www.facebook.com/professionalcpp ]

  3. #3
    Join Date
    Feb 2017
    Posts
    353

    Re: OK to write to pointer returned with consume semantics?

    Quote Originally Posted by GeoRanger View Post
    On one hand, I'd think this would be guaranteed to work because the memory being dereferenced to write the pointer "depends" on the pointer value, but on the other hand, it looks fishy to me and leaves me with some lingering doubts.
    In my view, if you're writing an ordinary application it's better to stick with the basics. Use a standard mutex to allow threads access to a section of code in a thread-safe manner, at least as a first approximation. It's only if this results in a performance bottleneck you need to optimize. And in that case most often the best solution is a high level re-design rather than a faster synchronization mechanism.
    Last edited by wolle; June 11th, 2018 at 05:01 AM.

Posting Permissions

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


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)