Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [vtp-dev] Race condition in application properties 
Although the recent changes correct the problem I was seeing it appears that they have caused a different problem.

Now when first creating an application sometimes the program freezes upon pressing the "Final" button in the wizard. 

I have traced the problem to a threading issue. When the main thread is processing storeConfig() it owns the lock to the VoiceToolsDesignProject object. The last thing it does is call postObjectEvent() which tries to get the lock on eventBuffer. It cannot get the lock and so stops there and waits forever.

The reason it cannot get the lock is that there is another thread running via the start() method of the DesktopCorePlugin class. The thread grabs the lock on the eventBuffer. The thread enters the processObjectEvent() method of a listener and does not return. The thread never returns from the method and so never calls wait() to give up the lock. Thus blocking the main thread from ever getting the lock on eventBuffer.

The reason the thread does not come back from the processObjectEvent() method of the listener is because the listener calls loadBuildPath() which wants the lock on the VoiceToolsDesignProject object since the loadBuildPath() method is now synchronized. It cannot have it yet because storeConfig() is still running and still owns that lock. 

So the main thread owns the lock that the other thread needs and the other thread owns the lock that the main thread needs.

Deadlock.

I have yet to come up with a fix for this so your help would be greatly appreciated.

-----Original Message-----
From: vtp-dev-bounces@xxxxxxxxxxx [mailto:vtp-dev-bounces@xxxxxxxxxxx] On Behalf Of vtp-dev-request@xxxxxxxxxxx
Sent: Thursday, April 30, 2009 11:01 AM
To: vtp-dev@xxxxxxxxxxx
Subject: vtp-dev Digest, Vol 43, Issue 31

Send vtp-dev mailing list submissions to
	vtp-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://dev.eclipse.org/mailman/listinfo/vtp-dev
or, via email, send a message with subject or body 'help' to
	vtp-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
	vtp-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of vtp-dev digest..."


Today's Topics:

   1. Re: Race condition in application properties settings
      (Trip Gilman)


----------------------------------------------------------------------

Message: 1
Date: Thu, 30 Apr 2009 11:00:37 -0500
From: Trip Gilman <trip@xxxxxxxxxxxxxxx>
Subject: Re: [vtp-dev] Race condition in application properties
	settings
To: Vtp-Dev <vtp-dev@xxxxxxxxxxx>
Message-ID: <C61F3555.9D39%trip@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

Thanks Tom,

    I moved the synchronized in the loadBuildPath to the method declaration
and added your suggestion to storeConfig.  Good find, and I appreciate you
posting it.

Trip Gilman


On 4/16/09 9:45 AM, "Johnson, Tom" <tom_johnson@xxxxxxxxxxxxxx> wrote:

> I believe that I found a race condition when configuring application
> properties. This is causing the configuration to sometimes lose data such as
> the language disappears when you change the media defaults.
>  
> It appears that when you update the application media defaults and then press
> OK that 
> org.eclipse.vtp.desktop.projects.core.internals.VoiceToolsDesignProject method
> storeConfig() is trying to update the .buildPath file at the same time as
> org.eclipse.vtp.desktop.editors.core.impl.ApplicationEditor method
> resourceChanged(). This can lead to elements disappearing from .buildPath.
>  
> The fix I put in  (on my copy of the baseline) was to synchronize the
> storeConfig() method in
> org.eclipse.vtp.desktop.projects.core.internals.VoiceToolsDesignProject so
> that it now looks like this:
>        public synchronized void storeConfig()
>  
> That seems to fix the issue.
>  
>  
>  
>  
>  
> 
> 
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/vtp-dev/attachments/20090430/77de583b/attachment.html

------------------------------

_______________________________________________
vtp-dev mailing list
vtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/vtp-dev


End of vtp-dev Digest, Vol 43, Issue 31
***************************************

Back to the top