On Fri, Apr 12, 2013 at 6:03 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 12/04/2013 10:38, Stefan Hajnoczi ha scritto: >>> > Yes, protect. Supposed we have HostMem A, and it will become B. Then >>> > hostmem_lookup will either see A or B. If it see A, it should use A >>> > refcnt agaist hostmem_listener_commit to drop A. This refcnt has no >>> > relation with mr's object's refcnt. >> My question is why you are accessing cur_hostmem outside hostmem_lock >> but then assigning it inside the lock on the next line... >> >>>>> > >> + cur_hostmem = next_hostmem; >> ...here. >> >> If you want an atomic exchange then tmp = cur_hostmem should be inside >> the lock. > > It will work because readers will grab either the hostmem_lock or the > BQL, while writers will grab both. A kind of local/global lock, but I'm No only hostmem_lock is used to protect readers from writers. While the writers are protected agaist each other by biglock. So leaving the "cur_hostmem = next_hostmem" outside to reflect the lock's rules.
Regards, Pingfan > not sure it was intentional. :) It's simpler to just move the read > inside the lock. > > Paolo
