compute-runtime

intel/compute-runtime

Fork 0

mirror of https://github.com/intel/compute-runtime.git synced 2025-12-26 07:00:17 +08:00

Commit Graph

Author	SHA1	Message	Date
Mrozek, Michal	a8b91c8c99	Refactor deducing blocked state and task level. - Do this with one helper function. Change-Id: I81dd3107a98db7e45a691ba6d5e708d98eabe3d2	2018-01-03 17:44:51 +01:00
Mrozek, Michal	ec59a900e1	Fix for deadlock in mapImage scenarios. - due to the fact that device mutex was obtained to prevent threaded access to image there was a problem when other thread was also doing readImage call That thread got read Image kernel mutex first and then it was acquiring device mutex, which was taken by other thread doing mapImage call. - In current code device mutex is not taken to service mapImage call, instead image is being guarded by its own mutex. Change-Id: Ic4c5a019708d7ec5b240bc5b08c5a65173827392	2018-01-03 12:33:12 +01:00
Brandon Fliflet	7e9ad41290	Initial commit Change-Id: I4bf1707bd3dfeadf2c17b0a7daff372b1925ebbd	2017-12-21 00:45:38 +01:00

Author

SHA1

Message

Date

Mrozek, Michal

a8b91c8c99

Refactor deducing blocked state and task level.

- Do this with one helper function.

Change-Id: I81dd3107a98db7e45a691ba6d5e708d98eabe3d2

2018-01-03 17:44:51 +01:00

Mrozek, Michal

ec59a900e1

Fix for deadlock in mapImage scenarios.

- due to the fact that device mutex was obtained to prevent threaded access to
image there was a problem when other thread was also doing readImage call
That thread got read Image kernel mutex first and then it was acquiring device
mutex, which was taken by other thread doing mapImage call.

- In current code device mutex is not taken to service mapImage call, instead
image is being guarded by its own mutex.

Change-Id: Ic4c5a019708d7ec5b240bc5b08c5a65173827392

2018-01-03 12:33:12 +01:00

Brandon Fliflet

7e9ad41290

Initial commit

Change-Id: I4bf1707bd3dfeadf2c17b0a7daff372b1925ebbd

2017-12-21 00:45:38 +01:00

3 Commits