Messages in this thread | | | Date | Thu, 27 Jun 2019 10:28:03 +0200 | From | Petr Mladek <> | Subject | Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation |
| |
On Wed 2019-06-26 23:43:56, John Ogness wrote: > Here is where I have massive problems communicating. I don't understand > why you say the barrier is _between_ newest and next. I would say the > barrier is _on_ newest to _synchronize_ with next (or something). I am > struggling with terminology. (To be honest, I'd much rather just post > litmus tests.) > > For example, if we have: > > WRITE_ONCE(&a, 1); > WRITE_ONCE(&b, 1); > WRITE_ONCE(&c, 1); > smp_store_release(&d, 1); > > and: > > local_d = smp_load_acquire(&d); > local_a = READ_ONCE(&a); > local_b = READ_ONCE(&b); > local_c = READ_ONCE(&c); > > How do you describe that? Do you say the memory barrier is between a and > d? Or between a, b, c, d? (a, b, c aren't ordered, but they are one-way > synchronized with d). > > I would say there is a barrier on d to synchronize a, b, c.
Barriers are always paired. We need to know what variables are synchonized against each other, what is the reason and where is the counter part.
I think that it might be done many ways. I am familiar with bariers in kernel/livepatch/ code. They use rather long description. But I find it pretty useful especially when the problem is complicated and more bariers are involved in a single transition.
Best Regards, Petr
| |