[fpc-devel] ref count types / threadsave question

[Benito van der Zander]

Hi Fpc Developers',

> Nobody is talking about the string content. 


But when they are stored together, that is the same. You can't get one 
without the other.


When core A creates a string to pass to core B, core A writes three 
things: ref count 1, the string content and the incremented ref count 2.

If core B could see stale data after the second write (with ref count 
1), it could also see stale data after the first write (without 
content). Nothing changes on core B between the writes.




> It's only about the reference count right now and that one *can* 
> differ between cores if that isn't correctly handled (even if the 
> string content stays the same). 

Sure one core can read 2 after the other core wrote 1.

I do not see how a core can read 1 after a 2 was written.

Cheers,
Benito

Am 03.01.19 um 14:23 schrieb Sven Barth via fpc-devel:
> Am Do., 3. Jan. 2019, 13:25 hat Benito van der Zander 
> <benito at benibela.de <mailto:benito at benibela.de>> geschrieben:
>
>     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 .
>
>
> Nobody is talking about the string content. It's only about the 
> reference count right now and that one *can* differ between cores if 
> that isn't correctly handled (even if the string content stays the same).
>
> Regards,
> Sven
>
>
> _______________________________________________
> 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/20190104/2acad028/attachment.html>