[libvirt] Potential race condition problem

[Guannan Ren]

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/3c3f1f82/attachment-0001.htm>