On Mon, May 10, 2021 at 10:59:40AM +0200, Emanuele Giuseppe Esposito wrote: > co-shared-resource is currently not thread-safe, as also reported > in co-shared-resource.h. Add a QemuMutex because co_try_get_from_shres > can also be invoked from non-coroutine context. > > Signed-off-by: Emanuele Giuseppe Esposito <[email protected]> > --- > util/qemu-co-shared-resource.c | 26 ++++++++++++++++++++++---- > 1 file changed, 22 insertions(+), 4 deletions(-)
Hmm...this thread-safety change is more fine-grained than I was
expecting. If we follow this strategy basically any data structure used
by coroutines needs its own fine-grained lock (like Java's Object base
class which has its own lock).
I'm not sure I like it since callers may still need coarser grained
locks to protect their own state or synchronize access to multiple
items of data. Also, some callers may not need thread-safety.
Can the caller to be responsible for locking instead (e.g. using
CoMutex)?
> diff --git a/util/qemu-co-shared-resource.c b/util/qemu-co-shared-resource.c
> index 1c83cd9d29..c455d02a1e 100644
> --- a/util/qemu-co-shared-resource.c
> +++ b/util/qemu-co-shared-resource.c
> @@ -32,6 +32,7 @@ struct SharedResource {
> uint64_t available;
>
> CoQueue queue;
> + QemuMutex lock;
Please add a comment indicating what this lock protects.
Thread safety should also be documented in the header file so API users
know what to expect.
signature.asc
Description: PGP signature
