Messages in this thread | | | Date | Sun, 23 Feb 2014 17:32:23 -0500 | From | Peter Hurley <> | Subject | Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK |
| |
Hi James,
On 02/23/2014 03:05 PM, James Bottomley wrote: > On Sat, 2014-02-22 at 14:03 -0500, Peter Hurley wrote: >> If it is necessary for a RELEASE-ACQUIRE pair to produce a full barrier, the >> ACQUIRE can be followed by an smp_mb__after_unlock_lock() invocation. This >> will produce a full barrier if either (a) the RELEASE and the ACQUIRE are >> executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on the >> same variable. The smp_mb__after_unlock_lock() primitive is free on many >> architectures. Without smp_mb__after_unlock_lock(), the critical sections >> corresponding to the RELEASE and the ACQUIRE can cross: >> >> *A = a; >> RELEASE M >> ACQUIRE N >> *B = b; >> >> could occur as: >> >> ACQUIRE N, STORE *B, STORE *A, RELEASE M > > Ah, OK, that's an error in the documentation.
AFAIK, Paul will not be changing the quoted text above.
> The example should read > > *A = a; > RELEASE *N* > ACQUIRE *M* > *B = b; > > The point being you can't have speculation that entangles critical > sections, as I've been saying, because that would speculate you into > ABBA deadlocks. Paul McKenny will submit a patch fixing the bug in > documentation.
The reason why there is no deadlock here is because the RELEASE M is not dependent on the ACQUIRE N to complete.
If the attempt to ACQUIRE N is speculated before the RELEASE M, two possibilities exist: 1. N is not owned, so the ACQUIRE is immediately successful, or 2. N is owned, so the attempted ACQUIRE is not immediately successful.
However, in both cases the RELEASE M will still complete, having already been started (since it occurred before in the instruction stream).
Regards, Peter Hurley
| |