DIP60: @nogc attribute

Michel Fortin via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 23 06:38:22 PDT 2014


On 2014-04-23 09:50:57 +0000, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at 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.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list