<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-template">Hi,<br>
<br>
<p>
<blockquote type="cite"><br>
<br>
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.
</blockquote>
</p>
</div>
<div><br>
</div>
<div>Is that really so? <br>
</div>
<div><br>
</div>
<div>The ref count is stored in the same memory block as the string
itself.<br>
</div>
<div><br>
</div>
<div>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 . <br>
</div>
<div><br>
Bye,<br>
Benito </div>
<br>
<div class="moz-cite-prefix">Am 02.01.19 um 21:52 schrieb Jonas
Maebe:<br>
</div>
<blockquote type="cite"
cite="mid:52276ff8-8f34-18c4-a786-1afedc5dc41a@freepascal.org">On
02/01/19 21:46, Martin Frb wrote:
<br>
<blockquote type="cite">On 02/01/2019 21:22, Benito van der Zander
wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
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?
<br>
</blockquote>
No:
<br>
<br>
// global var
<br>
var
<br>
Foo: String;
<br>
<br>
// main thread
<br>
Foo := getsomestring_with_refcount_1();
<br>
TMyThread.Create(false); // not suspended / start
<br>
<br>
Foo := ''; // de-ref
<br>
<br>
//TMyThread.Execute
<br>
LocalFoo := Foo; // copy from the global var
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
See e.g.
<a class="moz-txt-link-freetext" href="https://homes.cs.washington.edu/~bornholt/post/memory-models.html">https://homes.cs.washington.edu/~bornholt/post/memory-models.html</a>
for more information.
<br>
<br>
<br>
Jonas
<br>
_______________________________________________
<br>
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>
<br>
</blockquote>
</body>
</html>