[slawekptak]

Clarify the behavior of the event::get_wait_list() function for an event associated with a command, which has a dependency on an event, which was enqueued for signaling, after the command was submitted.

Add a unit test to confirm the described behavior.

Assisted-by: Claude

[gmlueck]

The Khronos WG decided to deprecate event::get_wait_list in SYCL-Next (see KhronosGroup/SYCL-Docs#1023). I suggest that we just say the value returned by this API is implementation-defined for reusable events. For example:

Calling event::get_wait_list for any event created via make_event returns an implementation-defined set of dependent events.

I think we should add similar language to KhronosGroup/SYCL-Docs#922.

[gmlueck]

Thinking about the implementation ... can we arrange for event::get_wait_list to return an empty vector when the event is created via make_event? That would be better than returning an irrelevant event in some cases.

[slawekptak]

I think there are two cases:

1. get_wait_list called on an event, which has been reused - the list is no longer valid, so we can just clear the list.
2. get_wait_list called on an event, which has a dependency on another event, which has been reused - that event is returned, but it is no longer part of the current event dependency list. I don't see an easy way to remove it from all of the dependency lists.

Also, currently all events are reusable - created via make_event, the default constructor and returned from queue submission. We can change this and have reusable and non-reusable events, but for this issue I don't think it would help. As long as a dependency can be set on a reusable event for the normal command submission, we have this issue.

Actually, the same question applies to KHR Launch. Do we allow for the same event use between KHR Launch and other SYCL APIs. I would say yes, since I'm not sure if we'd like a different type of event, dedicated for the use in that extension only.

There is also an interesting case of queue::ext_oneapi_get_last_event(). This is an experimental extension, so maybe not a big issue. If the last event has been reused, the queue no longer has a last event I guess, or it will return a outdated one by design.

I guess there are cases where we have to return a reused event in those functions. What do you think?

[gmlueck]

Thanks, I understand the problem. I think I'd word it slightly differently, though. My concern with the existing wording is that it's too specific, and people might think there is a guaranteed behavior in this case. Instead, I'd like to word it in a way that discourages users from using event::get_wait_list in this scenario. Maybe:

It is not recommended to call both enqueue_signal_event and event::get_wait_list for events in the same dependency chain. Consider the case when E1 represents the completion of command C, and C depends on some other event E2. If E2 is reassociated with with a new command via enqueue_signal_event, a subsequent call to E1.get_wait_list() may still return E2 even though E2 is no longer a dependency.

For the other case where E1 itself is reassociated with a new command, I think that E1.get_wait_list() should either:

• Return an empty set of dependent events (in which case we should document this behavior), or
• Return the actual set of dependent events for the new command it is associated with.

BTW, the WG decided to deprecate event::get_wait_list in the SYCL-Next specification, so I think most applications probably won't use this API.

[slawekptak]

I have updated the wording. Also, the call to get_wait_list() on a reassociated event is addressed here: #23591