Messages in this thread | | | Date | Thu, 24 Sep 2015 21:21:22 +0800 | From | Boqun Feng <> | Subject | Re: [PATCH] Documentation: Remove misleading examples of the barriers in wake_*() |
| |
Hi Peter,
On Thu, Sep 17, 2015 at 03:01:26PM +0200, Peter Zijlstra wrote: > On Thu, Sep 10, 2015 at 07:55:57PM +0200, Oleg Nesterov wrote: > > On 09/10, Boqun Feng wrote: > > > > > > On Wed, Sep 09, 2015 at 12:28:22PM -0700, Paul E. McKenney wrote: > > > > My feeling is > > > > that we should avoid saying too much about the internals of wait_event() > > > > and wake_up(). > > > > I feel the same. I simply can't understand what we are trying to > > document ;) > > So I've been sitting on this for a while and figured I'd finish it now. > > It are some notes on the scheduler locking and how it provides program > order guarantees on SMP systems. > > Included in it are some of the details on this subject, because a wakeup > has two prior states that are of importance, the tasks own prior state > and the wakeup state, both should be considered in the 'program order' > flow. >
Great and very helpful ;-)
> So maybe we can reduce the description in memory-barriers to this > 'split' program order guarantee, where a woken task must observe both > its own prior state and its wakee state. ^^^^^ I think you mean "waker" here, right?
And the waker is not necessarily the same task who set the @cond to true, right? If so, I feel like it's really hard to *use* this 'split' program order guarantee in other places than sleep/wakeup itself. Could you give an example? Thank you.
Regards, Boqun [unhandled content-type:application/pgp-signature] | |