[PATCH] RCU helper patchset 1/2
This first RCU helper patch adds a read_barrier_depends() primitive to all archs which is NOP for archs that doesn't require an rmb() for data dependent reads when writes are ordered using a wmb(). In reality, only alpha requires an rmb(), the rest are NOPs. It is likely to be necessary in most situations that would use RCU. Please apply. Description : Sometime ago, during a discussion on lock-free lookups, it was agreed that an additional memory barrier interface, read_barrier_depends() that is lighter than an rmb(), is necessary to make sure that data-dependent reads are not re-ordered over this barrier. For many processors, data-dependency enforces order, so this interface is a NOP, but for those that don't (like alpha), it can be a rmb(). For example, the following code would force ordering (the initial value of "a" is zero, "b" is one, and "p" is "&a"): CPU 0 CPU 1 b = 2; memory_barrier(); p = &b; q = p; read_barrier_depends(); d = *q; because the read of "*q" depends on the read of "p" and these two reads should be separated by a read_barrier_depends(). However, the following code, with the same initial values for "a" and "b": CPU 0 CPU 1 a = 2; memory_barrier(); b = 3; y = b; read_barrier_depends(); x = a; does not enforce ordering, since there is no data dependency between the read of "a" and the read of "b". Therefore, on some CPUs, such as Alpha, "y" could be set to 3 and "x" to 0. rmb() needs to be used here, not read_barrier_depends(). The original discussion can be found at - http://marc.theaimsgroup.com/?t=100259422200002&r=1&w=2 Explanation of the need for read_barrier_depends() can be found at http://lse.sf.net/locking/wmbdd.html
Showing
Please register or sign in to comment