[fpc-devel] volatile variables
DrDiettrich1 at aol.com
Wed Jun 29 17:57:47 CEST 2011
Nikolai Zhubr schrieb:
> 29.06.2011 15:28, Hans-Peter Diettrich:
>>>> But if so, which variables (class fields...) can ever be treated as
>>>> non-volatile, when they can be used from threads other than the main
>>> Without explicit synchronisation? Actually, none.
>> Do you understand the implication of your answer?
>> When it's up to every coder, to insert explicit synchronization whenever
>> required, how to determine the places where explicit code is required?
> All places where any non-readonly data could be accessed by 2 or more
> threads should be protected. Thats it.
Consider what this means to the RTL and other libraries. That code
typically is not thread-safe, so that it cannot be called safely from
threads. Doesn't this imply that in detail all application specific
objects must be either local to an thread, or must be protected against
concurrent access (shareable)?
This means that a simplified version of TThreadList would be nice, that
allows to wrap a single shareable object and make it usable in an
Possibly the language could be extended to help in the determination of
thread-(un)safe procedures. E.g. references to shareable objects could
be allowed only as "const" or "in" parameters, so that the compiler can
disallow persistent copies of such references. But like the C "const"
modifier, such a strict attribute may be problematic in many cases.
More information about the fpc-devel