[SYCL] Enqueue dependencies of blocked command

[s-kanaev]

Let's have this part of dependency graph:

  EC2 -> C2 -> EC1 -> C1

EC1 and EC2 are of helper type EmptyCommand. Both are blocked.
C1 and C2 are of any other type which represents some meaningful operation i.e. the one that actually does something useful, like ExecCGCommand with a host task or UpdateHostReqCommand for host accessor.
This part of graph is result of two submissions: the first one adds EC1 -> C1 and the second adds EC2 -> C2 -> EC1.
The submission process in both cases adds the corresponding Cx command in first place and then adds the empty command ECx. When Cx is added to the graph it's also added to list of leaves for corresponding memory record. Now, when ECx is added to graph it removes corresponding Cx from list of leaves. ECx is added to the list instead of Cx. Blocked state of ECx prevents it from being enqueued.

Upon the second submission, C2 isn't going to be enqueued right away as it depends on blocked EC1.

When C1 finishes (whether it is a host task or host accessor's update command) SYCL RT will unblock EC1 and trigger enqueue process for leaves of memory records C1 was depending by. Eventually, RT will enqueue the EC1 which will set its event into complete state. Though, EC2 isn't going to be enqueued due to it's blocked state. Neither does its dependencies.

PR with test: #2540
PR with comment fix: #2541

A more workaroundey way is available at #2542

[s-kanaev]

Need to fix unit-test

[DenisBakhvalov]

LGTM. I think this change likely will not pessimize the problem which was fixed by bc8f0a4.

[s-kanaev]

I think his change likely will not pessimize the problem which was fixed by bc8f0a4.

Is there any benchmark to check this assumption/hypothesis?

[DenisBakhvalov]

I think his change likely will not pessimize the problem which was fixed by bc8f0a4.

Is there any benchmark to check this assumption/hypothesis?

No, there is not. Only unit tests.

[s-kanaev]

I think that we should prefer #2561 instead of this one.

[s-kanaev]

Closing this PR as there is a more preferable solution in #2561