On Wednesday 28 September 2011, 14:49:56 Linus Torvalds wrote: > On Wed, Sep 28, 2011 at 11:08 AM, Stephan Diestelhorst > <stephan.diestelhorst@xxxxxxx> wrote: > > > > I must have missed the part when this turned into the propose-the- > > craziest-way-that-this-still-works.contest :) > > So doing it just with the "lock addb" probably works fine, but I have > to say that I personally shudder at the "surround the locked addb by > reads from the word, in order to approximate an atomic read of the > upper bits". > > Because what you get is not really an "atomic read of the upper bits", > it's a "ok, we'll get the worst case of somebody modifying the upper > bits at the same time". > > Which certainly should *work*, but from a conceptual standpoint, isn't > it just *much* nicer to say "we actually know *exactly* what the upper > bits were". Well, we really do NOT want atomicity here. What we really rather want is sequentiality: free the lock, make the update visible, and THEN check if someone has gone sleeping on it. Atomicity only conveniently enforces that the three do not happen in a different order (with the store becoming visible after the checking load). This does not have to be atomic, since spurious wakeups are not a problem, in particular not with the FIFO-ness of ticket locks. For that the fence, additional atomic etc. would be IMHO much cleaner than the crazy overflow logic. > But I don't care all *that* deeply. I do agree that the xaddw trick is > pretty tricky. I just happen to think that it's actually *less* tricky > than "read the upper bits separately and depend on subtle ordering > issues with another writer that happens at the same time on another > CPU". Fair enough :) Stephan -- Stephan Diestelhorst, AMD Operating System Research Center stephan.diestelhorst@xxxxxxx Tel. +49 (0)351 448 356 719 Advanced Micro Devices GmbH Einsteinring 24 85609 Aschheim Germany Geschaeftsfuehrer: Alberto Bozzo Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632, WEEE-Reg-Nr: DE 12919551 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
