1. Forum
  2. USENET
  3. cplusplus

  • memory_order_consume...

    From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Fri Oct 10 00:08:07 2025
    From Newsgroup: comp.lang.c++

    Well, is it std anymore? WTF! I don't want to have to use a damn acquire
    when I don't need to.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Bonita Montero@Bonita.Montero@gmail.com to comp.lang.c++ on Sat Oct 11 21:15:35 2025
    From Newsgroup: comp.lang.c++

    Am 10.10.2025 um 09:08 schrieb Chris M. Thomasson:

    Well, is it std anymore? WTF! I don't want to have to use a damn acquire when I don't need to.

    x86 doesn't have consume memory ordering so this maps to acuqire
    ordering.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Sat Oct 11 13:09:52 2025
    From Newsgroup: comp.lang.c++

    On 10/11/2025 12:15 PM, Bonita Montero wrote:
    Am 10.10.2025 um 09:08 schrieb Chris M. Thomasson:

    Well, is it std anymore? WTF! I don't want to have to use a damn
    acquire when I don't need to.

    x86 doesn't have consume memory ordering so this maps to acuqire
    ordering.

    Right, its implied on that arch. x86 has data dependent ordering. But I
    want to keep consume. For instance, it better not emit a damn acquire
    barrier on SPARC in RMO mode! Shit man.
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From jseigh@jseigh_es00@xemaps.com to comp.lang.c++ on Sat Oct 18 20:48:06 2025
    From Newsgroup: comp.lang.c++

    On 10/11/25 16:09, Chris M. Thomasson wrote:
    On 10/11/2025 12:15 PM, Bonita Montero wrote:
    Am 10.10.2025 um 09:08 schrieb Chris M. Thomasson:

    Well, is it std anymore? WTF! I don't want to have to use a damn
    acquire when I don't need to.

    x86 doesn't have consume memory ordering so this maps to acuqire
    ordering.

    Right, its implied on that arch. x86 has data dependent ordering. But I
    want to keep consume. For instance, it better not emit a damn acquire barrier on SPARC in RMO mode! Shit man.

    I was under the impression it was a data dependent load which isn't
    actually part of any memory models per se. For x86 it was documented
    in an appendix section, not the memory model section.

    I've used control dependency orderings but there's no memory barrier
    intrinsic for that. You get it from program control logic with
    maybe some compiler barriers if needed.

    Joe Seigh
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Chris M. Thomasson@chris.m.thomasson.1@gmail.com to comp.lang.c++ on Sun Oct 19 14:32:04 2025
    From Newsgroup: comp.lang.c++

    On 10/18/2025 5:48 PM, jseigh wrote:
    On 10/11/25 16:09, Chris M. Thomasson wrote:
    On 10/11/2025 12:15 PM, Bonita Montero wrote:
    Am 10.10.2025 um 09:08 schrieb Chris M. Thomasson:

    Well, is it std anymore? WTF! I don't want to have to use a damn
    acquire when I don't need to.

    x86 doesn't have consume memory ordering so this maps to acuqire
    ordering.

    Right, its implied on that arch. x86 has data dependent ordering. But
    I want to keep consume. For instance, it better not emit a damn
    acquire barrier on SPARC in RMO mode! Shit man.

    I was under the impression it was a data dependent load which isn't
    actually part of any memory models per se.

    Well, dec alpha aside for a moment...


    For x86 it was documented
    in an appendix section, not the memory model section.

    I've used control dependency orderings but there's no memory barrier intrinsic for that.-a You get it from program control logic with
    maybe some compiler barriers if needed.

    It should be a compiler barrier and only emit an explicit membar
    instruction on systems that require it, like an alpha. Actually, any
    atomic instruction even relaxed might cast an effect on the compiler optimization possibilities? volatile aside for a moment...


    --- Synchronet 3.21a-Linux NewsLink 1.2