[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] thread: add lock guard macros

From: Stefan Hajnoczi
Subject: Re: [PATCH 0/2] thread: add lock guard macros
Date: Wed, 11 Mar 2020 17:02:58 +0000

On Wed, Mar 11, 2020 at 04:06:02PM +0100, Paolo Bonzini wrote:
> Il mer 11 mar 2020, 15:50 Markus Armbruster <address@hidden> ha scritto:
> > Stefan Hajnoczi <address@hidden> writes:
> >
> > > Lock guards automatically call qemu_(rec_)mutex_unlock() when returning
> > from a
> > > function or leaving leaving a lexical scope.  This simplifies code and
> > > eliminates leaks (especially in error code paths).
> > >
> > > This series adds lock guards for QemuMutex and QemuRecMutex.  It does not
> > > convert the entire tree but includes example conversions.
> >
> > I support the move towards automatic cleanup, but I'm wary of
> > incremental conversion.  Experience tells that outdated examples
> > invariably get copied / imitated, with incremental conversion struggling
> > to keep up.
> >
> > Are we resigned to having both kinds of mutex cleanup forever?
> >
> There are cases where the legibility benefits of guards are debatable, or
> they require more complex functionality in the guards (see my other answer
> to Stefan). So, yes. We don't have that many mutexes so incremental
> conversion should be doable without taking forever.

I will add this to the BiteSizedTasks wiki page when the patch is
merged, together with guidelines on how to convert code (it requires
case-by-case evaluation and is not a simple mechanical change).

We will continue to have raw qemu_(rec_)mutex_lock/unlock() calls in
cases where a complex locking scheme is used or lock guards would make
the code less clear.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]