[fpc-devel] Suggestion: reference counted objects

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sun Sep 21 21:57:06 CEST 2014

Florian Klämpfl schrieb:
> Am 21.09.2014 um 07:22 schrieb Hans-Peter Diettrich:
>> Boian Mitov schrieb:
>>> That is easy. it gets incremented when it gets assigned. The running threads have no way of
>>> accessing it if there is no reference (assignment) already in place.
>> The problem arises when an object is destroyed, or even elected for destruction in _Release, while
>> another thread starts using the same instance.
> This is not possible for a correctly written program: if two threads having references to the same
> instance, the ref. count is 2. So no destruction is possible.

What happens if such a reference (to A) is part of another object (B), 
known to the thread? I suspect a chance for a race condition here, when 
one thread clears B.A while another thread tries to acquire a reference 
from B.A.

But this may be an excursion into threadsafe coding, where any 
modification to a shared resource requires a lock in a multi-threaded 
environment. Then above situation should never occur...

Is it really sufficient to protect refcounter changes by Interlocked 
Inc/Dec, to prevent race conditions while obtaining object references?


More information about the fpc-devel mailing list