Re: [libvirt] [PATCH 6/7] Switch to filtering based on log source name instead of filename

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.