diff options
author | Emanuele Giuseppe Esposito <eesposit@redhat.com> | 2022-09-26 05:31:58 -0400 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2022-10-07 12:11:41 +0200 |
commit | afe1e8a7b3e671993cf55e2321408650c7620999 (patch) | |
tree | 8ee15874f7c49500ca8bcb4267fe52dae152ccc5 /hw/block | |
parent | fd4b14e299d7def753f2d753e61d125cd5e1cbd8 (diff) | |
download | qemu-afe1e8a7b3e671993cf55e2321408650c7620999.zip qemu-afe1e8a7b3e671993cf55e2321408650c7620999.tar.gz qemu-afe1e8a7b3e671993cf55e2321408650c7620999.tar.bz2 |
job.c: add job_lock/unlock while keeping job.h intact
With "intact" we mean that all job.h functions implicitly
take the lock. Therefore API callers are unmodified.
This means that:
- many static functions that will be always called with job lock held
become _locked, and call _locked functions
- all public functions take the lock internally if needed, and call _locked
functions
- all public functions called internally by other functions in job.c will have a
_locked counterpart (sometimes public), to avoid deadlocks (job lock already taken).
These functions are not used for now.
- some public functions called only from exernal files (not job.c) do not
have _locked() counterpart and take the lock inside. Others won't need
the lock at all because use fields only set at initialization and
never modified.
job_{lock/unlock} is independent from real_job_{lock/unlock}.
Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20220926093214.506243-6-eesposit@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'hw/block')
0 files changed, 0 insertions, 0 deletions