[libvirt] Potential race condition problem
Benjamin Wang (gendwang)
gendwang at cisco.com
Sat Sep 29 13:06:12 UTC 2012
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 at redhat.com]
Sent: 2012年9月29日 17:22
To: Benjamin Wang (gendwang)
Cc: Daniel Veillard; libvir-list at redhat.com; Yang Zhou (yangzho); cbley at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120929/bf72310d/attachment-0001.htm>
More information about the libvir-list
mailing list