-
April 13th, 2015, 12:10 AM
#1
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
-
April 13th, 2015, 02:06 AM
#2
Re: InterlockedExchangeRelease doesn't exist?
Probably he means InterlockedCompareExchangeRelease function: https://msdn.microsoft.com/en-us/library/ff547867.aspx
-
April 13th, 2015, 04:16 AM
#3
Re: InterlockedExchangeRelease doesn't exist?
Originally Posted by GeoRanger
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.
Originally Posted by GeoRanger
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.
-
April 13th, 2015, 07:37 AM
#4
Re: InterlockedExchangeRelease doesn't exist?
Originally Posted by superbonzo
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).
-
April 13th, 2015, 11:33 AM
#5
Re: InterlockedExchangeRelease doesn't exist?
Originally Posted by OReubens
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...
-
April 13th, 2015, 03:01 PM
#6
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
-
April 14th, 2015, 06:53 AM
#7
Re: InterlockedExchangeRelease doesn't exist?
Originally Posted by Codeplug
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|