qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] Block layer complexity: what to do to keep it under con


From: Paolo Bonzini
Subject: Re: [Qemu-block] Block layer complexity: what to do to keep it under control?
Date: Wed, 29 Nov 2017 13:22:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 29/11/2017 13:16, Stefan Hajnoczi wrote:
> While the atomics documentation is good, atomics themselves have been a
> source of difficult bugs.
> 
> They should be used as little as possible and only where they can be
> encapsulated in a composable abstraction (i.e. don't expect users of
> your abstraction to understand atomics).
> 
> Why?  They are damn hard to use.  None of us is capable of using them
> without introducing difficult bugs.
> 
> There is also a temptation to rely on implicit effects of other code
> (e.g. when you know there is a barrier in another function) for best
> performance.  That's a bad property for code to have because it becomes
> hard to change safely.

I agree.  atomics.txt should be augmented with examples of well-known
idioms/patterns and a big red sign "if this is not what you're doing,
don't do it".

However, I'll note that in the end atomics are not very different from
very small critical sections.  If anything, atomics have the advantage
that you have to think more about acquire/release semantics.  So it's in
general a matter of "being as clever as you need, but not more than
that" (and IMO util/async.c and util/qemu-coroutine-lock.c do need all
the cleverness they can muster, but it should stop there).

Thanks,

Paolo

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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