[dmd-concurrency] shared arrays

[Steve Schveighoffer]

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
> Sent: Thu, January 14, 2010 3:57:12 PM
> Subject: Re: [dmd-concurrency] shared arrays
> 
> I understand. The thing is, shared means "can be changed by another thread at 
> any time" so I think the behavior you mention is 100% expectable.
> 
> If you want to do away with shared, you need to add synchronization.
> 
> I agree that the existence of multibyte characters constitute an argument in 
> favor of disabling certain operation. But as long as I can mess up a string in 
> one thread, I will be able to mess it up in several.

I just don't understand the dual standard.

Let's forget about long, and talk about arrays or any struct larger than a single int (but whose individual pieces are at most int size).  Why is it ok to copy a partially-modified string which is considered a whole unit, but it is not OK to copy a partially modified struct with two ints in it?  It's not like you can tear the ints, setting each is atomic.  It looks like the same issue to me, but the compiler refuses to compile one and happily accepts the other.

More inconsistency: I can currently cast a long[] into a ubyte[], so it would follow that I can cast a shared(long)[] into a shared(ubyte)[], no?  Then the compiler lets me copy the ubyte but not the long?

Any decision would be fine with me if the compiler was consistent for any aggregate type regardless of size -- either refuse to do it or allow it.

-Steve