Re: [PATCH] lockdep: Add a document describing crossrelease feature

From: Byungchul Park
Date: Wed Jul 06 2016 - 04:14:22 EST


On Wed, Jul 06, 2016 at 09:56:08AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 06, 2016 at 02:33:29PM +0900, Byungchul Park wrote:
> > On Wed, Jul 06, 2016 at 11:17:10AM +0900, Byungchul Park wrote:
> > >
> > > lock(A)
> > > wait_for(B)
> > > ~~~~~~~~~~~~~~~~~~~~~~~~ <- serialized by atomic operation
> > > lock(A)
> > > unlock(A)
> > > wake(B)
> > > unlock(A)
> >
> > By the way, I have a question. Is there anyone who could answer it?
> >
> > I want to serialize between two context's lock operations, for example,
> >
> > context A context B
> > -------------- --------------
> > lock A
> > lock B ...
> > lock C
> > atomic_inc_return
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <- serialization
> > atomic_read
> > lock D
> > ... lock E
> > lock F
> >
> > so that we can see these in the order like A -> B -> C -> D -> E -> F.
> >
> > atomic_inc_return() is used after lock C in context A, and atomic_read()
> > is used before lock D in context B. And I want to make it serialized when
> > the atomic_read() can see the increased value.
> >
> > Can I use smp_mb__after_atomic() just after atomic_read()
>
> No. atomic_set() and atomic_read() are not RmW operations.
>
> > or should I use
> > smp_mb()? I think anyway I have to choose one of them for that ordering.
>
> smp_load_acquire(), if that observes the increment it will ensure D
> comes after etc..
>
> Also, atomic_read() _could_ be enough, if its part of a control
> dependency, because LOCK very much involves a store, so the load->store
> order provided by the control dependency will already order things.

Indeed. Thank you very much.

I can rely on the control dependency if possible. I will check it.

Thank you,
Byungchul