At beginning of June I've found the following link on the ReactOS mailing list when they were discussing about memory ordering and volatile as well: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt

For those interested the following is the link to the starting discussion: http://www.reactos.org/archives/public/ros-dev/2011-June/014277.html (I hope the mail thread works in the web view as well as in my mail client)

Regards,
Sven

On 28.06.2011 13:14, Michael Schnell wrote:
A similar discussion is going on in Lazarus-develop, but this obviously
is a compiler question.


In C, there is the volatile keyword that ensures that after the code
sequence enters the next C instruction after that which modified this
variable, another thread sees the correct state of the variable.

This is ensured by not caching the value in registers and on SMP systems
additionally by low level stuff like memory barriers.

Of course this does not protect concurrent read-modify-write accesses
(same need to be protected by low level atomic instructions or MUTEX and
friend).

For variables not defined as volatile, (e.g.) pthread_mutex (and similar
stuff on Windows) can be used to protect them.

AFAIK, in Pascal all Global (Static) variables are considered to be
handled as volatile, so no problem here (other than handling all of them
them as volatiles might decrease performance slightly).

But what about variables on the heap ? If class instance variables or -
say - a liked list done with records created by "new" are accessed by
multiple threads, how can said consistency be enforced ?

Even if you use a critical section to do the protection, this does not
help if the compiler decides to cache the variable in a register while
entering or exiting the critical section.

But even without dedicated protection, a volatile variable should be
able to be be monitored from another thread. Can this be enforced in
Pascal for help variables ?

-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to