Re: [vtp-dev] Race condition in application properties

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Thanks Tom,

I've posted this to bugzilla ticket #275473.  We've really just started to
leverage bugzilla to keep track of defects.  If you create an account on the
eclipse bugzilla site, I can add you to the CC list of bugs created based on
your mailings or you could go ahead post any issues you find directly there.
It's up to you, either way works for me.

Anyways, I think I've got a possible fix for this issue.  I realized that a
recent change that added IDs to brands was not propagated to the templates
used to create the initial files.  This was causing new applications and
fragment projects to immediately write the config while reading it as the
newly assigned IDs would have to be stored.  I have committed the fix to SVN
(revision 20651).  Let me know if you get it to break again.

Trip


On 5/8/09 9:59 AM, "Johnson, Tom" <tom_johnson@xxxxxxxxxxxxxx> wrote:

> 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
> ***************************************
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev