Recent

Author Topic: Documentation inambiquates  (Read 3283 times)

HeavyUser

  • Sr. Member
  • ****
  • Posts: 310
Documentation inambiquates
« on: September 04, 2015, 03:44:07 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8731
  • FPC developer.
Re: Documentation inambiquates
« Reply #1 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.

HeavyUser

  • Sr. Member
  • ****
  • Posts: 310
Re: Documentation inambiquates
« Reply #2 on: September 05, 2015, 02:46:48 am »
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.
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8731
  • FPC developer.
Re: Documentation inambiquates
« Reply #3 on: September 05, 2015, 02:46:52 pm »
What happens in the non threading targets like dos?

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.

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.
« Last Edit: September 05, 2015, 02:49:01 pm by marcov »

HeavyUser

  • Sr. Member
  • ****
  • Posts: 310
Re: Documentation inambiquates
« Reply #4 on: September 05, 2015, 03:32:10 pm »
What happens in the non threading targets like dos?

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.

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
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.

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.
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.
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.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8731
  • FPC developer.
Re: Documentation inambiquates
« Reply #5 on: September 05, 2015, 05:05:24 pm »

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.

A simple multithreading based on a timeslicer won't run into it either since it still won't use more than one core.

 

TinyPortal © 2005-2018