[SYCL] Guard access to the cache of device lib programs #6094
Conversation
We cache device library programs (like fallback assertion) in the context. In multi-threaded applications simultaneous access to the cache of device lib programs is possible in program_manager::build(). That's why access to the this cache needs to be guarded to avoid data race.
There was a problem hiding this comment.
This looks good to me. I'd probably make a few infrastructure changes but those shouldn't be tied to this PR:
template <typename T>
class Lockable {
public:
class Locked {
/* Same as before, plus */
public:
T* operator->() { ... }
};
Locked aquire() { return {...} }
const T* operator->() { ... } // Not sure if read should be allowed without lock.
private:
T obj;
std::mutex M;
};
|
@againull - It seems this is causing post-commit failure in SchedulerTests on Windows. Could you please investigate? |
Yes, I am investigating. |
It turned out that the fail is unrelated to this change. We have a tracker for this issue and Andrei is working on it. |
|
@againull, @aelovikov-intel, fwiw revert seems make test pass. I've triggered failing testing manually at: https://github.com/intel/llvm/actions/runs/2284512659 |
We cache device library programs (like fallback assertion) in the
context. In multi-threaded applications simultaneous access to the
cache of device lib programs is possible in program_manager::build().
That's why access to the this cache needs to be guarded to avoid data
race.