On 21 March 2014 13:16, Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: > Wonderful! I was going to do this today, but thanks a lot for taking > care of this for me! I just wanted to finish this long lasting thread as soon as possible. > We need this assignment to happen exactly at this point, that is, *after* > the call to post_transition() completes and before calling wake_up(). > > If the compiler or the CPU reorders the instructions and moves this > assignment to some other place, then we will be in trouble! > > We might need memory barriers to ensure this doesn't get reordered. > Alternatively, we can simply hold the spin-lock around this assignment, > since locks automatically imply memory barriers. As an added advantage, > the code will then look more intuitive and easier to understand as well. > > Thoughts? I may be wrong but this is how I understand locks. Yes, spinlocks have memory barriers implemented but it wouldn't guarantee what you are asking for in the above explanation. It will guarantee that transition_ongoing will be updated after the lock is taken but the notification() can happen after the lock is taken and also after the variable is modified. You can find some information on this in Documentation/memory-barriers.txt I don't think compiler or CPU will reorder calls to a function and updates of a variable. And so this code might simply work. And I hope there would be plenty of such code in kernel. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
