On 02/01/19 21:22, Benito van der Zander wrote:
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?
The problem is that the different cores may see different values. Core 1
could see that the refcount is 1 (wrong) while core 2 could see that is
2 (correct) unless you add memory barriers (directly, or indirectly by
using atomic read-modify-write instructions).
UniqueString has such a test:
Function fpc_ansistr_Unique(Var S : Pointer): Pointer; [Public,Alias :
'FPC_ANSISTR_UNIQUE']; compilerproc; inline;
{
Make sure reference count of S is 1,
using copy-on-write semantics.
}
begin
pointer(result) := pointer(s);
If Pointer(S)=Nil then
exit;
if PAnsiRec(Pointer(S)-AnsiFirstOff)^.Ref<>1 then
result:=fpc_truely_ansistr_unique(s);
end;
This function is indeed not threadsafe (and it cannot be made 100%
threadsafe, although it could be made a bit safer —and slower— by
changing the check into an atomic inc/decrement with 0 and checking that
the result is 1).
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
