On 6/28/22 16:08, Emanuele Giuseppe Esposito wrote:
Am 24/06/2022 um 20:22 schrieb Vladimir Sementsov-Ogievskiy:
I've already acked this (honestly, because Stefan do), but still, want
to clarify:
On 6/16/22 16:18, Emanuele Giuseppe Esposito wrote:
job mutex will be used to protect the job struct elements and list,
replacing AioContext locks.
Right now use a shared lock for all jobs, in order to keep things
simple. Once the AioContext lock is gone, we can introduce per-job
locks.
To simplify the switch from aiocontext to job lock, introduce
*nop* lock/unlock functions and macros.
We want to always call job_lock/unlock outside the AioContext locks,
and not vice-versa, otherwise we might get a deadlock.
Could you describe here, why we get a deadlock?
As I understand, we'll deadlock if two code paths exist simultaneously:
1. we take job mutex under aiocontext lock
2. we take aiocontex lock under job mutex
If these paths exists, it's possible that one thread goes through [1]
and another through [2]. If thread [1] holds job-mutex and want to take
aiocontext-lock, and in the same time thread [2] holds aiocontext-lock
and want to take job-mutext, that's a dead-lock.
If you say, that we must avoid [1], do you have in mind that we have [2]
somewhere? If so, this should be mentioned here
If not, could we just make a normal mutex, not a noop?
Of course we have [2] somewhere, otherwise I wouldn't even think about
creating a noop function. This idea came up in v1-v2.
Regarding the specific case, I don't remember. But there are tons of
functions that are acquiring the AioContext lock and then calling job_*
API, such as job_cancel_sync in blockdev.c.
I might use job_cancel_sync as example and write it in the commit
message though.
Yes, that's obvious that we have tons of [1]. That's why an example of [2]
would be lot more valuable.
--
Best regards,
Vladimir