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
<ben...@benibela.de <mailto:ben...@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@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
