Re: wake_up_process implied memory barrier clarification

[Boqun Feng <boqun.feng@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

Hi Paul,

On Mon, Aug 31, 2015 at 01:37:39PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 31, 2015 at 08:33:35PM +0200, Oleg Nesterov wrote:
> > On 08/31, Boqun Feng wrote:
> > >
> > > Fair enough, I went too far. How about just a single paragraph saying
> > > that:
> > >
> > > The wake_up(), wait_event() and their friends have proper barriers in
> > > them, but these implicity barriers are only for the correctness for
> > > sleep and wakeup. So don't rely on these barriers for things that are
> > > neither wait-conditons nor task states.
> > >
> > > Is that OK to you?
> > 
> > Ask Paul ;) but personally I agree.
> > 
> > To me, the only thing a user should know about wake_up/try_to_wake_up
> > and barriers is that you do not need another barrier between setting
> > condition and waking up.
> 
> Sounds like an excellent idea in general.  But could you please show me
> a short code snippet illustrating where you don't need the additional
> barrier, even if the fastpaths are taken so that there is no sleep and
> no wakeup?
> 

If there is no sleep and no wakeup, it means only CONDITION changed.
Either CONDITION is a single variable or it should maintains internal
ordering guarantee itself. And there is no need for barriers, because
there is only one shared resource we are talking about, right?

But I'm still a little confused at Oleg's words:

"What is really important is that we have a barrier before we _read_ the
task state."

I read is as "What is really important is that we have a barrier before
we _read_ the task state and _after_ we write the CONDITION", if I don't
misunderstand Oleg, this means a STORE-barrier-LOAD sequence, which IIUC
can't pair with anything.

So, there might be some tricky barrier usage here?

Regards,
Boqun

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]