Can properties be atomic?

[kapibara]

Types like Booleans and Integers are atomic and can be accessed from threads without being protected by a critical section, but what if for example an integer is accessed by way of a PROPERTY instead:

Code: [Select]

TAtomicClass = (class)
private
  FAtomicValue: Integer;
public
  property AtomicValue: Integer read GetAtomic write SetAtomic;
end;
(I omitted the implementation of the getters and setters)

Does it matter if the getting and setting of the property AtomicValue is done directly to FAtomicValue, using no getter/setter methods?

Code: [Select]

property AtomicValue: Integer read FAtomicValue write FAtomicValue;

[taazz]

Types like Booleans and Integers are atomic and can be accessed from threads without being protected by a critical section, but what if for example an integer is accessed by way of a PROPERTY instead:

Code: [Select]

TAtomicClass = (class)
private
  FAtomicValue: Integer;
public
  property AtomicValue: Integer read GetAtomic write SetAtomic;
end;
(I omitted the implementation of the getters and setters)

Does it matter if the getting and setting of the property AtomicValue is done directly to FAtomicValue, using no getter/setter methods?

Code: [Select]

property AtomicValue: Integer read FAtomicValue write FAtomicValue;

Integer operations are not atomic at least that is what I remember, anyway moving on to the actual question no it makes no difference if you access atomic types through the get/set methods or directly through the private variable in both cases the operation that needs protecting is the actual transfer of the data from the private variable (aka the global data in this case) to the Result variable after that because the result variable is part of the method it can not be corrupted from other threads or thread switching.

There is a big cotcha in here though just because the access of the atomic type is thread safe that does not make the get/set methods thread safe by it self.

[jc99]

To clarify let's make an example.
I use this class, making one variable like

Code: [Select]

aAtomicClass := TAtomicClass.create()
I make n-Theads writing a large prime to aAtomicClass.AtomicValue from a set of primes.
Each Thread writes exactly one number.
In the main program I read values from aAtomicClass.AtomicValue
I should only read primes from the orginal set of primes.
Is that a correct assumption ?

[taazz]

To clarify let's make an example.
I use this class, making one variable like

Code: [Select]

aAtomicClass := TAtomicClass.create()
I make n-Theads writing a large prime to aAtomicClass.AtomicValue from a set of primes.
Each Thread writes exactly one number.
In the main program I read values from aAtomicClass.AtomicValue
I should only read primes from the orginal set of primes.
Is that a correct assumption ?

A large prime number is not something easily defined as atomic best define something else but lets assume that your large prime is a 32bit integer and your cpu guarantees that all 32bit read and write are atomic then No you assume that the reading thread will read after at least one writing thread has written a number which is.... well.... unsafe.

[jc99]

A large prime number is not something easily defined as atomic best define something else but lets assume that your large prime is a 32bit integer and your cpu guarantees that all 32bit read and write are atomic then No you assume that the reading thread will read after at least one writing thread has written a number which is.... well.... unsafe.

Sorry I should be more clear what i meant with large. Desepite of 1,2,3,5,7,11,13 which all share the same high-bytes, I meant 32-bit primes, not really large prime like (2^57,885,161 − 1).
So the only unsafe thing is that i could read the initialization value, because no thread has written to it.
So putting the initialization value to the set (or simply init the thing with a value of the set),
Is it still possible to get a variable not in the set ? Or even worse is it possible that the program hangs, blocks or does a SIGSEGV ?
 

[taazz]

A large prime number is not something easily defined as atomic best define something else but lets assume that your large prime is a 32bit integer and your cpu guarantees that all 32bit read and write are atomic then No you assume that the reading thread will read after at least one writing thread has written a number which is.... well.... unsafe.

Sorry I should be more clear what i meant with large. Desepite of 1,2,3,5,7,11,13 which all share the same high-bytes, I meant 32-bit primes, not really large prime like (2^57,885,161 − 1).
So the only unsafe thing is that i could read the initialization value, because no thread has written to it.
So putting the initialization value to the set (or simply init the thing with a value of the set),
Is it still possible to get a variable not in the set ? Or even worse is it possible that the program hangs, blocks or does a SIGSEGV ?
 

https://software.intel.com/en-us/forums/topic/308940 So no int32 operations are not atomic lets assume that in your cpu they are and you have already initialized the variable to a prime number before the threads start then yes it is impossible to read non prime numbers.

[jc99]

https://software.intel.com/en-us/forums/topic/308940 So no int32 operations are not atomic lets assume that in your cpu they are and you have already initialized the variable to a prime number before the threads start then yes it is impossible to read non prime numbers.

The intel Q&A talks about incrementing and decrementing a 32-bit value, that always include a reading, processing and writing stage, with a prefech-Queue it's even more possible of a thread intercepting here.
But we are talking about plain reading and writing operations.
When you do:

Code: [Select]

aAtomicClass.AtomicValue := aAtomicClass.AtomicValue +1;
That's definitely unsafe.

[taazz]

https://software.intel.com/en-us/forums/topic/308940 So no int32 operations are not atomic lets assume that in your cpu they are and you have already initialized the variable to a prime number before the threads start then yes it is impossible to read non prime numbers.

The intel Q&A talks about incrementing and decrementing a 32-bit value, that always include a reading, processing and writing stage, with a prefech-Queue it's even more possible of a thread intercepting here.
But we are talking about plain reading and writing operations.
When you do:

Code: [Select]

aAtomicClass.AtomicValue := aAtomicClass.AtomicValue +1;
That's definitely unsafe.

The rules for atomic operations may be found in Chapter 7, Locked Atomic Operations, of the IA-32 Intel Architecture Software Developers Manual, Volume 3: System Programming Guide (http://developer.intel.com/design/Pentium4/documentation.htm). Here, it is guaranteed that simple loads or stores will be automatically atomic as long as the memory location is aligned on the appropriate boundary (16-bit boundary for 16-bit values, 32-bit boundary for 32-bit values, and so forth). In addition, simple loads or stores that are not aligned on the appropriate boundary are still guaranteed to be executed atomically if the 16, 32, or 64-bit values fit completely within a 32-byte cache line

those are the rules of atomicity on intel processors for loads and stores aka read and writes. Again unless the compiler has a define that can force the above rules on integers then you should consider them non atomic or use Pointer to integers and make sure that they are aligned as needed your self. In any case you need to make sure that the operation will be atomic and I do not see how since even the memory the application uses is virtual so it is up to the system to give you properly aligned memory or not and lie about it or not.

[kapibara]

Thanks guys!

[BitBangerUSA]

nice Topic and Posts. also saying 'Thanks.'

[jc99]

BTW: is there a operation like
  SaveInc, a thread save incrementation and decrementation, that can be compiled to an optimized code like

Code: [Select]

  LOCK
  INC [...]
if the targeted processor has such a feature, so you have to use a semaphore ?

[taazz]

BTW: is there a operation like
  SaveInc, a thread save incrementation and decrementation, that can be compiled to an optimized code like

Code: [Select]

  LOCK
  INC [...]
if the targeted processor has such a feature, so you have to use a semaphore ?

interlockedXXXX suite of procedures function are thread safe eg http://lazarus-ccr.sourceforge.net/docs/rtl/system/interlockedincrement.html it has interlockedDecrement exchange and others.

[jc99]

interlockedXXXX suite of procedures function are thread safe eg http://lazarus-ccr.sourceforge.net/docs/rtl/system/interlockedincrement.html it has interlockedDecrement exchange and others.

[Yeah!] [Beer!] [Jumping for Joy]
That really helped me, and solved a bunch of my optimizing-problems.
Thanks a lot.