On 03/10/2014 04:18 AM, Daniel P. Berrange wrote: > On Fri, Mar 07, 2014 at 11:05:28AM -0700, Eric Blake wrote: >> On 03/03/2014 12:18 PM, Daniel P. Berrange wrote: >>> Both >>> of these options have a notable performance impact, however, and >>> it is believed that worst case behaviour where the fields are >>> read concurrently with being written would merely result in an >>> mistaken emissions or dropping of the log message in question. >>> This is an acceptable tradeoff for the performance benefit of >>> avoiding locking. >>> >> >> Almost. As long as writes are safe, the worst that can happen is we >> fail to emit a message that just got enabled, or we emit a message that >> just got disabled. But had we used locks to avoid this race, and the >> locks get obtained in reverse order, we would see the same behavior. So >> the locks add no protection, and eliding them in favor of simpler >> non-atomic integer ops is a safe action. >> >> If there were only a single writer, then writes would be automatically >> safe. However, you have multiple writers. Thus, you have the situation >> that if two writers both try to increment the global serial with no >> locks or atomic increments, you could end up with the classic symptoms >> of over- or under-incrementing the global serial. If three threads compete: >> > > The writes are already protected by a mutex so I don't think we need > to use atomic ops for increment either. > > > These two functions run with the global log mutex held, so there can > only be one writer at a time. Ah, I missed the bigger picture. Indeed, the increments happen while the mutex is held, so ACK. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list