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
crashes.
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)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
