Concurrency help (modifying the workspace) [message #488441] |
Mon, 28 September 2009 16:58 |
Mark Melvin Messages: 118 Registered: July 2009 |
Senior Member |
|
|
Hi There,
I have some code that uses a set of ProjectScope preference settings that is starting to give me major concurrency headaches. Not being an expert on things, I need a bit of advice.
Currently, I have concurrency issues that have arisen as a result of me moving to the common navigator. This isn't the common navigator's fault - my code was never really threadsafe, and now it is being hammered from many threads at once. My initial attempts at simple synchronization failed and caused deadlocks (mostly due to my builder executing the same code in the context of an autobuild, and the platform locking the workspace).
Basically, what I need to do is refactor my code to avoid calling #flush() on my project-scoped preference nodes from many different threads, but also deal with the cases where I absolutely *need* to have the preference node flushed before I can move on. This is the tough part.
Let's say I absolutely need to flush my project preferences to disk, but I am being called in the context of an automatic build, and the workspace is locked. How can I avoid deadlocks in this situation? What is the proper way for me to ensure the project preference node is flushed (waiting for it if necessary), without deadlocking the platform? I realize you can "join" the autobuild job, but it is not really that simple. The ProjectPreferences#save method jumps through some hoops to try to avoid this very issue, so I am tempted to just rely on it's behavior here. But things get pretty hairy and I am a little unsure of how to properly do this, having been burned in the past.
What is the best way to avoid these types of deadlocks if two things are both trying to lock/modify a project in the workspace? Is there a specific strategy using the Jobs or Resources API?
Thanks,
Mark.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03308 seconds