I would appreciate further review of this fix.
As you state, its follows a pattern of
acquire SchedulingRule
synchronized (some object)
{meaty stuff}
release ScheduleingRule
I think this is still deadlock prone, unless *all* clients use exact same pattern.
If, for example, somewhere else, only synchronized is used, AND ends up calling back to this code, then I think deadlock will occur.
Is it known (or, at least documented) that this is the pattern all clients should use?
My guess is not, and that's why you are using synchronized block to begin with.
Or, perhaps, synchronized part is not needed at all? And could do all with scheduleing rules?
I must confess, this was from my quick reivew of the patch ... so I may be mis-reading it, or
these issues may be well (better!) understood,
but just thought I'd request the education for myself.
Thanks,
| Chuck Bridgham/Raleigh/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED] 03/30/2006 12:00 PM
|
|
Have fix that first acquires lock based on scheduling rules, then uses the object monitor locks. finally it releases the lock through the JobManager.
This will avoid deadlocks with other processes that also use scheduling rules.
Tested locally
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email: [EMAIL PROTECTED]
Phone: 919-254-1848 (T/L: 444)_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
