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.
