On 02/01/19 21:46, Martin Frb wrote:
On 02/01/2019 21:22, Benito van der Zander wrote:
Hi,
but if another core can do anything to the string, the refcount should
already be 2, one for this core and one for the other core, should it not?
No:
// global var
var
Foo: String;
// main thread
Foo := getsomestring_with_refcount_1();
TMyThread.Create(false); // not suspended / start
Foo := ''; // de-ref
//TMyThread.Execute
LocalFoo := Foo; // copy from the global var
This is a different issue. Managed types are indeed only threadsafe as
long as there is no race condition that could cause their refcount to
become zero at some point.
The issue I was talking about is the fact that atomic operations do
function as global memory synchronisation operations across all cores
(at least not on all architectures). If core 1 atomatically increases
refcount to two and you "then" load the same refcount normally (without
an atomic read-modify-exchange oepration) on another core, this other
core may still see the old value.
The reason "then" is between quotes is because there is no forced
ordering between these two operations (since there is no
synchronisation/memory barrier linking the the two), which is also the
basis of the problem.
See e.g.
https://homes.cs.washington.edu/~bornholt/post/memory-models.html for
more information.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
