should pure functions accept/deal with shared data?
Alex Rønne Petersen
alex at lycus.org
Wed Jun 6 18:32:07 PDT 2012
On 07-06-2012 03:07, Andrei Alexandrescu wrote:
> On 6/6/12 6:01 PM, Alex Rønne Petersen wrote:
>> (And of course, neither is actually implemented in any compiler, and I
>> doubt they ever will be.)
>
> Why do you doubt shared semantics will be implemented?
>
> Andrei
>
I think there are two fundamental issues making implementation difficult
and unlikely to happen:
1) The x86 bias (I replied to your other post wrt this).
2) The overall complexity of generating correct code for shared.
If we ignore the portability issues that I pointed out in my other
reply, point (1) is irrelevant. I'm fairly certain the shared semantics
that people expect can be implemented just fine at ISA level on x86
without dirty hacks like locks. But if we do care about portability
(which we ***really*** should - ARM and PowerPC, for example, are
becoming increasingly important!), then we need to reconsider shared
very carefully.
The thing about (2) is that literally every operation on shared data has
to be special-cased in the compiler. This adds a crazy amount of
complexity, since there are basically two code paths for every single
part of the code generation phase: the unshared path and the shared
path. This is mostly caused by the fact that shared is transitive and
can be applied to virtually any type. But even if we ignore that
complexity, we have the problem of certain operations that cannot be
atomic (even though they may look like it):
* Would you expect an array indexing operation (where the array slice is
shared) to index the array atomically? Would you expect the read of the
value at the calculated memory location to be atomic?
* Would you expect a slicing operation to be atomic? (Slicing something
involves reading two words of memory which cannot be done atomically
even on x86.)
* Would you expect 'in' to be atomic? (It can only really, kinda-sorta
be if you use locks inside the AA implementation...)
etc.
--
Alex Rønne Petersen
alex at lycus.org
http://lycus.org
More information about the Digitalmars-d
mailing list