On Tue, Sep 01, 2015 at 11:40:14AM +0800, Boqun Feng wrote: > 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?
I could imagine all sorts of combinations, which is why I would like to see a code snippet showing exactly what Oleg is talking about. ;-) Thanx, Paul > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/