Forum > General
Documentation inambiquates
HeavyUser:
I'd like to point out that the documentation for Interlockedxxxxxxxx suite of functions is unclear in at least two ways.
1) Access from a single processor and thread safe are not equal I need to know if the functions are executed as atomic making it impossible to leave the data in a broken state after a thread switch or not. If the answer can not cover all the supported CPU then a list of CPU/
2) the InterlockedCompareExchange does not define what happens if the comparison fails. It returns 0 for numeric and nil for pointers? The returned value is undefined? Something else? If the result is undefined can you introduce an overloaded function that will return true/false making sure that the result is always defined?
Thank you for your time.
PS. I did not see any documentation specific forum if this is the wrong forum for this question I would appreciate a pointer to the correct one.
marcov:
Afaik they are simply equivalent to the winapi functions of the same name, except non threading targets like dos. So they are multiple cpu safe.
HeavyUser:
--- Quote from: marcov on September 04, 2015, 04:10:09 pm ---Afaik they are simply equivalent to the winapi functions of the same name, except non threading targets like dos. So they are multiple cpu safe.
--- End quote ---
What happens in the non threading targets like dos? And why does it make any difference if the OS is threading or not? I though that the interlocked family of functions where based on the cpu ability for atomic operations not the OS multithreading capabilities.
marcov:
--- Quote from: HeavyUser on September 05, 2015, 02:46:48 am ---What happens in the non threading targets like dos?
--- End quote ---
There it doesn't matter since no two threads on two different CPUs or cores will ever contend to access the same memory spot, so every access is atomic by default. Even the OS (=DOS) part abides by that.
--- Quote --- And why does it make any difference if the OS is threading or not? I though that the interlocked family of functions where based on the cpu ability for atomic operations not the OS multithreading capabilities.
--- End quote ---
Usually they are abstracted by the OS in some way. Some other synchronization primitives might need to interact with the scheduler (to block instead of busy waiting).
This post gives an idea what might need to be added to the cpu primitives (e.g. 32-bit primitives in 32-bit apps on 64-bit systems), and of course also a guarantee that all fences are in place.
HeavyUser:
--- Quote from: marcov on September 05, 2015, 02:46:52 pm ---
--- Quote from: HeavyUser on September 05, 2015, 02:46:48 am ---What happens in the non threading targets like dos?
--- End quote ---
There it doesn't matter since no two threads on two different CPUs or cores will ever contend to access the same memory spot, so every access is atomic by default. Even the OS (=DOS) part abides by that.
--- End quote ---
Actually it does matter it doesn't do what advertises and it would be far better to raise an exception than to silently drop atomicity. I was hopping to write some short of multi threading lib for dos as an exercise and this little detail would have land me in a lot of trouble. Any way now I know and it does not affect me for the time being, thank you.
--- Quote from: marcov on September 05, 2015, 02:46:52 pm ---
--- Quote --- And why does it make any difference if the OS is threading or not? I though that the interlocked family of functions where based on the cpu ability for atomic operations not the OS multithreading capabilities.
--- End quote ---
Usually they are abstracted by the OS in some way. Some other synchronization primitives might need to interact with the scheduler (to block instead of busy waiting).
This post gives an idea what might need to be added to the cpu primitives (e.g. 32-bit primitives in 32-bit apps on 64-bit systems), and of course also a guarantee that all fences are in place.
--- End quote ---
From a quick look on the various links in that page my gut reaction is too much smoke not enough fire, specifically and I quote from the second paragraph on link of the accepted answer
--- Quote ---A simple read or write on a field of 32 bits or less is always atomic. Operations on 64-bit fields are guaranteed to be atomic only in a 64-bit runtime environment.
--- End quote ---
That statement along tells me that I need to test every single statement on that article before accepting any conclusions it makes so this will take some time.
As for the interlocked operations they supposed to be atomic and atomic operations are a bit too low level to be abstracted like that they are not normal synchronization primitives and can't be handled like one or if you like to handle them like normal primitives then the compiler should provide an other way to access the atomic instructions, can't comment on the "fences" idea until I see what those fences are.
Aaaaaaany way its a mute point thank you for your time and hopefully this kind of information will be included in the documentation at some point.
Navigation
[0] Message Index
[#] Next page