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