<p>Am 22.09.2014 11:22 schrieb "Michael Schnell" <<a href="mailto:mschnell@lumino.de">mschnell@lumino.de</a>>:<br>
><br>
> On 09/22/2014 11:13 AM, Sven Barth wrote:<br>
>><br>
>><br>
>> 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.<br>
>><br>
> Yep. it will work.<br>
><br>
> 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).<br>
><br>
> OTOH ARC might be "interesting" (but supposedly not really advantageous) with parallel processing for creating thread-local objects in certain cases.</p>
<p>Then you should also not use interfaces, strings and arrays, because they use the same mechanisms.</p>
<p>><br>
><br>
>> Note: ARC doesn't change that the developer him-/herself needs to make his/her classes threadsafe. ARC only "protects" the references.<br>
>><br>
> Adding even more confusion to developing multithreaded projects :-(</p>
<p>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.<br>
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.<br>
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).</p>
<p>Regards,<br>
Sven</p>