[fpc-devel] ref count types / threadsave question

[Benito van der Zander]

Hi,

>
>
> 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. 


Is that really so?

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 .

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 at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190103/61bc87e8/attachment.html>