`Array.events` spuriously synchronizes on read-after-read

[inducer]

• There should be Array.write_events and Array.read_events, with Array.events aliasing write_events under a deprecation.
• Arguments to all the generated kernels (elementwise etc.) should declare whether they're writing and automatically add to the appropriate events list.
• Audit code calling into the kernels to avoid duplicate event insertion.

cc @alexfikl @zachjweiner

[zachjweiner]

If I'm recalling correctly, I think the idea was that once we can distinguish between read- and write-synchronization points, there will be no need to enforce the order of two kernels based on an array that they both (only) read. For example, the operations y = 2 * x and y_h = 2 * x.get() do not need to be ordered, but the first would add an event to x.events which the call to get would wait for. In principle they could execute asynchronously, but Array's event tracking enforces this synchronization at the moment (because it has no way to know that neither execution modifies x).

Does this make sense?

[inducer]

Thanks for explaining, I remember now. The current Array.events system needs to be redone to wait on reads before making in-place changes.

!91 adds synchronization for WAR in .get(), but the overall issue is more general, IMO.

This is really what gl-19 was meant to capture. (which we'll have this issue subsume)

[inducer]

@zachjweiner Could you remind me which way this issue went? According to my experiments, I believe 2*x does not currently add the resulting event to x.events (as of a60b4ed), so there's is not currently spurious synchronization. But I could see an argument that there should be synchronization for 2*x, to ensure that nobody modifies x before 2*x is done reading. Was this the core of the issue?

[zachjweiner]

I believe 2*x does not currently add the resulting event to x.events

I find the same - it seems events are only appended to self in array.py and never other.

But I could see an argument that there should be synchronization for 2*x, to ensure that nobody modifies x before 2*x is done reading. Was this the core of the issue?

Yes, I believe so. And I definitely believe the argument.

Looking back at gl-18 I see we discussed this issue with regard to calls to Array.get. And it does seem that the MR did add the get event to Array.events.

PS - I think #302 can be (read: was intended to be) closed.