[SYCL] Removed mutex leading to deadlock

[KarachunIvan]

Imagine the situation, when there is a global buffer, and several threads
trying to write some data in it. Each thread creates a host accessor to the
buffer and writes its id into the memory.
When a host accessor is created, SYCL RT creates two commands:
UpdateHostRequirement and EmptyCommand.
So SYCL execution graph will look like this:

... -> [EmpCmd T2] -> [UpdReq T2] -> [EmpCmd T1] -> [UpdReq T1] -> [AllocaBuf]

An EmptyCommand acts like mutex: it blocks all operations execution which were
created after host accessor creation while host accessors is "alive".
Let's assume that thread #2 first started an execution by enqueueing UpdReq T2
command. But the command cannot be started since its execution is blocked by
EmpCmd T1. Since thread #2 locked the mutex in Scheduler::waitForEvent,
thread #1 hangs on this mutex, which leads to deadlock.

Signed-off-by: Ivan Karachun ivan.karachun@intel.com

[s-kanaev]

Suppose a deadlock happens.
Will the test framework deal with it?

[KarachunIvan]

I'm not sure, but I guess the task might be killed by lit infrastructure due to execution timeout.

[romanovvlad]

Imagine the situation, when there is a global buffer, and several threads
trying to write some data in it. Each thread creates a host accessor to the
buffer and writes its id into the memory.
When a host accessor is created, SYCL RT creates two commands:
UpdateHostRequirement and EmptyCommand.
So SYCL execution graph will look like this:

... -> [EmpCmd T2] -> [UpdReq T2] -> [EmpCmd T1] -> [UpdReq T1] -> [AllocaBuf]

An EmptyCommand acts like mutex: it blocks all operations execution which were
created after host accessor creation while host accessors is "alive".
Let's assume that thread #2 first started an execution by enqueueing UpdReq T2
command. But the command cannot be started since its execution is blocked by
EmpCmd T1. Since thread #2 locked the mutex in Scheduler::waitForEvent,
thread #1 hangs on this mutex, which leads to deadlock.

Signed-off-by: Ivan Karachun ivan.karachun@intel.com

Description contains to many details not really related to the issue.
Suggest simplifying to something like this:

1. thread1: add nodes to the graph for host accessor A1 to the buffer B
2. thread2: add nodes to the graph for host accessor A2 to the buffer B
3. thread2: wait for host accessor A2 nodes to complete
4. thread1: wait for host accessor A1 nodes to complete

wait on step 3 blocks the mutex, but waits because for host accessor A1 to be destructed.
wait on step 4 cannot complete because the mutex is locked.

[KarachunIvan]

Imagine the situation, when there is a global buffer, and several threads
trying to write some data in it. Each thread creates a host accessor to the
buffer and writes its id into the memory.
When a host accessor is created, SYCL RT creates two commands:
UpdateHostRequirement and EmptyCommand.
So SYCL execution graph will look like this:
... -> [EmpCmd T2] -> [UpdReq T2] -> [EmpCmd T1] -> [UpdReq T1] -> [AllocaBuf]
An EmptyCommand acts like mutex: it blocks all operations execution which were
created after host accessor creation while host accessors is "alive".
Let's assume that thread #2 first started an execution by enqueueing UpdReq T2
command. But the command cannot be started since its execution is blocked by
EmpCmd T1. Since thread #2 locked the mutex in Scheduler::waitForEvent,
thread #1 hangs on this mutex, which leads to deadlock.
Signed-off-by: Ivan Karachun ivan.karachun@intel.com

Description contains to many details not really related to the issue.
Suggest simplifying to something like this:

1. thread1: add nodes to the graph for host accessor A1 to the buffer B
2. thread2: add nodes to the graph for host accessor A2 to the buffer B
3. thread2: wait for host accessor A2 nodes to complete
4. thread1: wait for host accessor A1 nodes to complete

wait on step 3 blocks the mutex, but waits because for host accessor A1 to be destructed.
wait on step 4 cannot complete because the mutex is locked.

Commit message was updated.

[s-kanaev]

LGTM

[s-kanaev]

minor

Suggested change

	MThreadPool.push_back(std::thread(func, args...));
	MThreadPool.emplace_back(std::forward(func), std::forward(args)...);

[KarachunIvan]

Applied