Hi Paul, in patch "Documentation/memory-barriers.txt: Downgrade UNLOCK+BLOCK" (sic), you wrote: + Memory operations issued before the LOCK may be completed after the + LOCK operation has completed. An smp_mb__before_spinlock(), combined + with a following LOCK, orders prior loads against subsequent stores + and stores and prior stores against subsequent stores. Note that Is there a "and stores" too many? Or was one "stores" mistyped and meant to be something else? Or what else is meant? @@ -1677,13 +1681,57 @@ LOCK, and an access following the UNLOCK to happen before the UNLOCK, and the two accesses can themselves then cross: *A = a; - LOCK - UNLOCK + LOCK M + UNLOCK M *B = b; may occur as: - LOCK, STORE *B, STORE *A, UNLOCK + LOCK M, STORE *B, STORE *A, UNLOCK M + +This same reordering can of course occur if the LOCK and UNLOCK are +to the same lock variable, but only from the perspective of another +CPU not holding that lock. The example says "LOCK M" and "UNLOCK M" (since the patch). I read this as LOCK and UNLOCK to the same variable, M. Why does the following sentence then say that "this same reordering can... occur if the LOCK and UNLOCK are to the same lock variable"? This sentence would make sense if the example had been about LOCK M, UNLOCK N. +In short, an UNLOCK followed by a LOCK may -not- be assumed to be a full +memory barrier because it is possible for a preceding UNLOCK to pass a +later LOCK from the viewpoint of the CPU, but not from the viewpoint +of the compiler. Note that deadlocks cannot be introduced by this +interchange because if such a deadlock threatened, the UNLOCK would +simply complete. So rather than deadlock, "the UNLOCK would simply complete". But /why/ does it complete? It is left unclear (to me at least), why it would do so. IOW, what mechanism will make it always proceed to the UNLOCK? Without knowing that, it is left entirely unclear (to me) why the deadlock wouldn't happen. -- Stefan Richter -=====-====- --=- =-=== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
