On 12/03/2013 06:55 AM, Daniel P. Berrange wrote: >> Not as far as I can tell. Since only one thread is setting the >> variable, and we are not accessing the variable in a signal handler, it >> seems that mere 'volatile' is enough to ensure that the compiler won't >> optimize any out-of-order assignments. I'm fine giving ACK to this >> patch as-is. > > I wasn't thinking of ordering, but rather atomicity of updating > the value. eg what happens if thread 1 tries to read the value > concurrently with thread 2 setting it. Surely this is the case > atomic ops are intended for. Still no problem. You're thinking of two threads trying to write a variable, where there is a race on which value gets written. But with one thread writing exactly once, and the other thread reading, you get exactly one of two well-defined behaviors: The reader is first, which means initialization hasn't yet completed, so we skip cleanup (rare, but the case of the BZ we are trying to fix) The writer is first, which means initialization has completed and the cleanup thread can clean up (the common case). -- 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