Messages in this thread | | | Date | Wed, 6 Jul 2016 17:12:26 +0900 | From | Byungchul Park <> | Subject | Re: [PATCH] lockdep: Add a document describing crossrelease feature |
| |
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
| |