Re: [libvirt] Potential race condition problem

Hi, I think you misunderstand my meaning. My solution includes step1 + step2. Step1 is used to implement thread mutex. Step2 is used to handle “initialized” visibility. Without step2, the initialization could be executed several times. B.R. Benjamin Wang From: Guannan Ren [mailto:gren@redhat.com] Sent: 2012年9月29日 17:22 To: Benjamin Wang (gendwang) Cc: Daniel Veillard; libvir-list(a)redhat.com; Yang Zhou (yangzho); cbley(a)av-test.de Subject: Re: [libvirt] Potential race condition problem On 09/29/2012 03:52 PM, Benjamin Wang (gendwang) wrote: Hi, OK. Now I am using JNA to access libvirt. If we add another mutex which used to access “initialized” parameter. This mutex must be pthread_mutex_init firstly and only once. But it seems that there is no way to change libvirt code. I do it as following: 1. Changing libvirt JNA code in Connect.java Old Code: public Connect(String uri) throws LibvirtException { VCP = libvirt.virConnectOpen(uri); // Check for an error processError(); ErrorHandler.processError(Libvirt.INSTANCE); } New Code: public Connect(String uri) throws LibvirtException { synchronized(this.getClass()) { VCP = libvirt.virConnectOpen(uri); } // Check for an error processError(); ErrorHandler.processError(Libvirt.INSTANCE); } This can make sure only that one thread can execute Connect. For a server application, we only need one time. So the performance is OK 2. Changing libvirt code in libvirt.c Old Code: static int initialized = 0; New Code: static int volatile initialized = 0; This can make sure the initialization will be executed once. Would you give your comments for this solution? B.R. Benjamin Wang As far as I know the operations on volatile variable is not atomic, the usage of volatile keyword as a portable synchronization mechanism is discouraged by C. But in Java, it is a global ordering on the reads and writes to a volatile variable. So, maybe, your first solution is pretty enough good. Guannan