[fpc-devel] ref count types / threadsave question

Martin Frb lazarus at mfriebe.de
Sun Jan 6 16:41:21 CET 2019

On 06/01/2019 16:17, Martin Frb wrote:
> The idea was
> - local variables of a procedure/function
> - with a ref count of 1
> Such a variable could in the epilogue be freed, without a "locked dec 
> ref".
> (actually not limited to the epilogue, but wherever the compiler 
> inserts such a decref)

To rephrase it a bit simpler.

There are 2 ways threads can share strings (or dyn array)

1) Using the same variable.
In that case every access to the variable must be protected 
(synchronize, lock, ... => mem barrier in place)
If not, then if the string is relocated (size changed) or freed, it is 
not guaranteed that all threads see the new value.

Therefore using the same variable in several threads, without mem 
barrier, means that the code already has race conditions that lead to 

If in this case a thread sees a refcount of 1 and wants to decrement it, 
the thread must be in a mem barrier/lock => no other thread has access 
to the variable. Save to free the string.

2) Using one (or more) variable per thread. Each variable is exclusive 
to that thread.
The initial copy to that variable must be taken in a way according to 
point 1 above. Therefore all threads are guaranteed to see a ref count 
of 2 or higher.

If the refcount goes back to 1, then only one thread has access to the 
string. And another thread can only get access via a mem barrier technique.

Threads are not guaranteed to see the refcount going back to 1.
- If they do not, the use the save locked decr. Which will ensure they 
see the correct value.
- If they do see the refcount at 1, then they can trust that value. (no 
other thread can have changed it since it went to 1)

More information about the fpc-devel mailing list