On 2014-04-23 09:50:57 +0000, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com> said:
On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote:
Objective-C isn't memory safe because it lets you play with raw
pointers too. If you limit yourself to ARC-managed pointers (and avoid
undefined behaviours inherited from C) everything is perfectly memory
safe.
I'm not convinced that it is safe in multi-threaded mode. How does ARC
deal with parallell reads and writes from two different threads? IIRC
the most common implementations deals with read/read and write/write,
but read/write is too costly?
The answer is that in the general case you should protect reads and
writes to an ARC pointer with locks. Otherwise the counter risk being
getting out of sync and later you'll get corruption somewhere.
There are atomic properties which are safe to read and write from
multiple threads. Internally they use the @synchronized keyword on the
object.
But since there's no 'shared' attribute in Objective-C, you can't go
very far if you wanted the compiler to check things for memory safety.
That said, if you assume a correct implementation of the NSCopying
protocol (deep copying), objects following that protocol would be safe
to pass through a std.concurrency-like interface.
In all honesty, I'm not that impressed with the multithreading
protections in D either. It seems you so often have to bypass the type
system to make something useful that it doesn't appear very different
from not having them. And don't get me started with synchronized
classes...
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
