Hi,
03.01.2019 15:25, Benito van der Zander:
The ref count is stored in the same memory block as the string itself.
If core 2 could not see the new ref count, it could not see what is in
the string and thus not use the string for anything .
If string content modification is supposed to be possible and the said
string is accessible by 2 or more threads, then some sort of explicite
syncronization will need to be used (like with many other cases of data
sharing across multiple threads). Pascal does not provide complete
automatic thread-safety for strings (AFAIK). It does provide automatic
lifecycle management (refcounting) only.
Regards,
Nikolai
Bye,
Benito
Am 02.01.19 um 21:52 schrieb Jonas Maebe:
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
<mailto:fpc-devel@lists.freepascal.org>
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
