[fpc-devel] Suggestion: reference counted objects

[Sven Barth]

Am 22.09.2014 11:22 schrieb "Michael Schnell" <mschnell at lumino.de>:
>
> On 09/22/2014 11:13 AM, Sven Barth wrote:
>>
>>
>> Interfaces, strings and arrays already work well in multi threaded
contexts and ARC will use the same mechanisms here, so there is no need to
discuss "parallel" and ARC together.
>>
> Yep. it will work.
>
> But one point speaking against ARC is performance possible degradation,
This of course is critical when trying to improve performance by using
multiple cores in parallel. As the ref counting needs atomic operation,
this is especially critical, because same are even more expensive when the
variables are accessed by multiple cores (and hence reside in multiple
caches).
>
> OTOH ARC might be "interesting" (but supposedly not really advantageous)
with parallel processing for creating thread-local objects in certain cases.

Then you should also not use interfaces, strings and arrays, because they
use the same mechanisms.

>
>
>> Note: ARC doesn't change that the developer him-/herself needs to make
his/her classes threadsafe. ARC only "protects" the references.
>>
> Adding even more confusion to developing multithreaded projects :-(

What us confusing there? You already need to take care about the thread
safety of your classes yourself and the refcounting will even relief you of
having to think of one thing, namely when to free an object.
Let's imagine this: you have two threads in addition to a mainthread that
use a common class, let's say a queue. Currently you would most likely
instantiate the queue before you instantiate the threads and pass tee queue
along in their constructors. To free the queue you would wait until both
threads have terminated.
Now with reference counting you would still pass along the queue, but you
wouldn't need to care about freeing it, because it would be freed
automatically once all three threads no longer hold a reference on the
queue object. There's no race condition here, because even if all three
threads would lose the reference at once there are only three references to
lose to begin with and once the count reaches zero the object is freed.
Because once the count is zero there can no longer be a reference to this
object and thus no one can manipulate the reference count anymore (it's of
course simplyfied, because with the interaction with non reference counted
variables I mentioned you could play around this, but I'm talking about the
standard case here).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140922/72f1494b/attachment.html>