Some missing things in the current threading implementation

[Sönke Ludwig]

Am 12.09.2010 17:00, schrieb Michel Fortin:
>> 9. unique
>>
>> Unique objects or chunks of data are really important not only to be
>> able to check that a cast to 'immutable' is correct, but also to allow
>> for passing objects to another thread for computations without making
>> a superfluous copy or doing superfluous computation.
>
> Indeed, no-aliasing guaranties are important and useful, and not only
> for multithreading. But unique as a type modifier also introduce other
> complexities to the language, and I can understand why it was chosen not
> to add it to D2. I still wish we had it.
>
>
>> 11. holes in the system
>>
>> It seems like there are a lot of ways in which you can still slip in
>> non-shared data into a shared context.
>
> Your examples are just small bugs in spawn. They'll eventually get fixed.
>
> If you want a real big hole in the type system, look at the destructor
> problem.
> <http://d.puremagic.com/issues/show_bug.cgi?id=4621>
>
> Some examples of bugs that slip by because of it:
> <http://d.puremagic.com/issues/show_bug.cgi?id=4624>
>
>
>> 12. more practical examples need to be considered
>>
>> [...]
>>
>> III. multiple threads computing separate parts of an array
>
> If we had a no-aliasing guaranty in the type system (unique), we could
> make a "splitter" function that splits a unique array at the right
> positions and returns unique chunks which can be accessed independently
> by different cores with no race. You could then send each chunk to a
> different thread with correctness assured. Without this no-aliasing
> guaranty you can still implement this splitter function, but you're
> bound to use casts when using it (or suffer the penalty of atomic
> operations).
>

If the language allows for creating an array, splitting it and 
processing the chunks in separate threads - and that without any cast in 
the user part of the code + the user code is safely checked - I think 
everything would be fine. Of course a full solution in the language 
would be ideal, but my worries are more that in general you have to 
leave the checked part of the type system so often, that all that type 
checking might be completely useless as only the most simple threading 
constructs are checked. In that way a library solution that hides the 
casts and still guarantees (almost) safe behaviour would already be a 
huge step forward.

Maybe a UniqeArray(T) type that is library checked and that you can pass 
through spawn() would be a sufficient solution to at least this problem. 
It could make sure that T is POD and that only operations are allowed 
that still guarantee uniqueness of the elements.