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?
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;
Bye,
Benito
Am 02.01.19 um 20:14 schrieb Jonas Maebe:
On 02/01/19 20:08, Martin wrote:
If a local string var has a refcount of 1, then it can not be
accessed by any other thread. Therefore it needs no lock for
decreasing the ref.
You would need a full memory barrier before checking whether the
reference count is one, otherwise it could have been increased to two
by another thread on another core quite a while ago without that
change being already visible on the current core. This would probably
slow down things much more than any potential gain from not performing
the atomic decrement.
Jonas
_______________________________________________
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
