Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1342962
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores |
| Date | 2016-02-25 09:30 +0100 |
| Message-ID | <r5Zt8-120-19@gated-at.bofh.it> (permalink) |
| References | <r5zS2-84d-11@gated-at.bofh.it> <r5A1J-87D-37@gated-at.bofh.it> <r5P0K-1T4-9@gated-at.bofh.it> <r5PtM-2bk-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Feb 24, 2016 at 01:40:13PM -0800, Paul E. McKenney wrote:
> > > + (*) If both legs of the "if" statement begin with identical stores to
> > > + the same variable, then those stores must be ordered, either by
> > > + preceding both of them with smp_mb() or by using smp_store_release()
> > > + to carry out the stores. Please note that it is -not- sufficient
> > > + to use barrier() at beginning of each leg of the "if" statement,
> > > + as optimizing compilers do not necessarily respect barrier()
> > > + in this case.
> Let's take the example, replace barrier() with smp_mb(), and see what
> happens:
>
> q = READ_ONCE(a);
> if (q) {
> smp_mb();
> WRITE_ONCE(b, p);
> do_something();
> } else {
> smp_mb();
> WRITE_ONCE(b, p);
> do_something_else();
> }
Why would an optimizing compiler be allowed to lift _anything_ over a
barrier() ? Isn't that a bug?
I thought the whole point of barrier() was to tell the compiler to not
do such things.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH tip/core/rcu 0/14] Documentation updates for 4.6 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 01/14] documentation: Add real-time requirements from CPU-bound workloads "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 14/14] documentation: Clarify compiler store-fusion example "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 12/14] documentation: Document illegality of call_rcu() from offline CPUs "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 07/14] documentation: Distinguish between local and global transitivity "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 05/14] documentation: Remove obsolete reference to RCU-protected indexes "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 08/14] documentation: Add alternative release-acquire outcome "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 11/14] documentation: Transitivity is not cumulativity "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 04/14] documentation: Add synchronize_rcu_mult() to the requirements "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:10 +0100
[PATCH tip/core/rcu 13/14] documentation: Explain how RCU's combining tree fights contention "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
[PATCH tip/core/rcu 10/14] documentation: Explain why rcu_read_lock() needs no barrier() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
[PATCH tip/core/rcu 03/14] documentation: Fix memory-barriers.txt section references "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
[PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2016-02-24 22:20 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 22:50 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores Jianyu Zhan <nasa4836@gmail.com> - 2016-02-25 07:50 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 15:10 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores Peter Zijlstra <peterz@infradead.org> - 2016-02-25 09:30 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 15:10 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores Peter Zijlstra <peterz@infradead.org> - 2016-02-25 15:50 +0100
Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-25 16:50 +0100
[PATCH tip/core/rcu 06/14] documentation: Subsequent writes ordered by rcu_dereference() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-24 06:20 +0100
csiph-web