CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    Join Date
    Mar 2006
    Posts
    151

    InterlockedExchangeRelease doesn't exist?

    This article, "Acquire and release sound like bass fishing terms, but they also apply to memory models" <http://blogs.msdn.com/b/oldnewthing/...3/8969397.aspx>, seems to provide a good explanation of acquire and release semantics. However, "InterlockedExchangeRelease" doesn't seem to exist, though the article makes such a function appear both sensible and necessary.

    Can someone knowledgeable on the subject please explain? Is the article wrong in its example and if so what are "normal" usage patterns for the acquire and release versions of all the Interlocked* functions?

    Thank you!
    GeoRanger

  2. #2
    Join Date
    Jul 2002
    Posts
    2,543

    Re: InterlockedExchangeRelease doesn't exist?

    Probably he means InterlockedCompareExchangeRelease function: https://msdn.microsoft.com/en-us/library/ff547867.aspx

  3. #3
    Join Date
    Oct 2008
    Posts
    1,456

    Re: InterlockedExchangeRelease doesn't exist?

    Quote Originally Posted by GeoRanger View Post
    This article [...] seems to provide a good explanation of acquire and release semantics
    IMHO, it does not, because one is left with the impression that those mysterious memory "accesses" can happen in the wrong order for some mysterious reasons.

    in my view, in order to have a consistent understanding of synchronization, one should either refer to some abstract concurrency model that rigorously defines what operations and their execution ordering relations are ( for example, the c++11 threading model ) or one should refer to the actual cpu cache coherency protocol to see which memory fences a cpu supports/needs and use the compiler atomic api accordingly.

    Quote Originally Posted by GeoRanger View Post
    However, "InterlockedExchangeRelease" doesn't seem to exist, though the article makes such a function appear both sensible and necessary.
    AFAIK, on x86 all stores and reads have release and aquire semantics, respectively ( as longs as the compiler does not reorder instructions, of course; that is, if an InterlockedXXX api is used )
    so, an InterlockedExchange ( = read+write ) cannot have release only semantics, it can be either relase+acquire or acquire.

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

    Re: InterlockedExchangeRelease doesn't exist?

    Quote Originally Posted by superbonzo View Post
    IMHO, it does not, because one is left with the impression that those mysterious memory "accesses" can happen in the wrong order for some mysterious reasons.
    maybe because that impression is exactly what is happening.

    The "mystery" here is the CPU doing (sub)instruction reordering. So even if the compiler generates code that guarantees assembly level correct ordering, things can still get messed up in the processor pipeline.
    That's why a compiler cannot make synchronisation guarantees without specific support from the CPU or the OS.

    AFAIK, on x86 all stores and reads have release and aquire semantics, respectively ( as longs as the compiler does not reorder instructions, of course; that is, if an InterlockedXXX api is used )
    so, an InterlockedExchange ( = read+write ) cannot have release only semantics, it can be either relase+acquire or acquire.
    Not entirely correct, see above. CPU (sub)instruction reordering.
    Even if the compiler does no reordering, there is no guarantee the CPU won't.
    UNLESS you use the CPU 'lock' on the instruction, and you are right there, the x86 instruction set only has a single 'lock' prefix which serves as both acquire and release.
    This 'lock' actually goes further than just making sure the CPU doesn't reorder accesses for itself across the lock, but also takes care of locking the address lines so no other CPU in the system can access that memory for the duration of the instruction (important in Read, Modify, Store type instructions like Or, And, Xor, Xchg, ...) which can take more than 1 clockcycle to complete.


    ALso, you'll find references to InterlockedXxxAcquire and InterlockedXxxRelease type instructions on MSDN because those are supported in Windows when running on the Itanium processor. A processor that Microsoft will no longer be supporting (and hasn't been since Windows 8).

  5. #5
    Join Date
    Oct 2008
    Posts
    1,456

    Re: InterlockedExchangeRelease doesn't exist?

    Quote Originally Posted by OReubens View Post
    maybe because that impression is exactly what is happening.
    uhm no, it's not ( never claimed that reordering does not occur ); my point basically was that speaking of "memory accesses" and "ordering of operations" in vague and undefined terms ( as the cited article does ) does not explain anything at all, it just adds to confusion...

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

    Re: InterlockedExchangeRelease doesn't exist?

    >> those are supported in Windows when running on the Itanium processor.
    I wonder if they are there for ARM... I'm too lazy to look in the SDK.

    gg

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

    Re: InterlockedExchangeRelease doesn't exist?

    Quote Originally Posted by Codeplug View Post
    I wonder if they are there for ARM... I'm too lazy to look in the SDK.
    Mmmm... nope.

    ARM has been a hardware model that didn't have much in the way of guaranteed efficient atomics for the most part because it didn't need to. Arm has traditionally been SMP and in that respect, it can't ever trip over it's own feet. It simply needed a basic "enable/disable interrupts" type feature (similar to x86's sti/cli instructions).

    It's actually quite amazing and visionary of intel back in the mid 1970's to design the 8086 with the "lock" instruction already there.

    ARM v8 does have ldra/strl instructions and as such goes from a big step behind x86 to small step ahead of x86 by having separate acquire and release semantics. ANy processor implementing ARM V8 for 32bit or 64bit will have ldra/strl as mandatory requirements. 16bit and 8bit arm V8 have it as optional, but from what I've gathered about V8, it's unlikely that any 8/16bit variants of the ARMv8 will be made, and if there are, there's little reason to not support the full instruction set.

    I'm not sure what type of ARM windows will be supporting, but if they do go V8, then yes, we'll probably see those InterlockedXxxAcquire and ..Release variants being supported on ARMv8

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