[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse.org-architecture-council] [Bug 246840] [discussion] How to use Jobs and ISchedulingRule properly?
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246840
Product/Component: Platform / Runtime
--- Comment #1 from John Arthorne <john_arthorne@xxxxxxxxxx> 2008-09-10 21:04:24 -0400 ---
When writing a contains() method I think the best approach is to view the space
of all possible scheduling rules representing a forest of directed trees, where
an edge from A->B means A.contains(B) is true. If you introduce new rules,
you're safe as long their contains relation still describes one or more
directed trees. In this tree scenario, isConflicting can simply be defined as
A.isConflicting(B) iff A.contains(B) or B.contains(A). One could theoretically
write more complex DAGs of rules that would still work, but will likely be
confusing to work with.
Scheduling rules need to be acquired all at once to prevent deadlock. This
eliminates the "hold and wait" condition that is one of the necessary
conditions for deadlock (http://en.wikipedia.org/wiki/Deadlock). With this
design deadlock between scheduling rules is impossible (I know there are other
deadlock prevention strategies, but none that seem to work well in an Eclipse
component world where it is often impossible to know much about the code
calling you, or the code you are calling).
MultiRule arises from the need to hold multiple locks at once. If you acquire
one after the other, deadlock is possible. You must acquire them all at once
for deadlock to be impossible. Hence MultiRule.
RuleFactory arises from the need you touched on of information hiding. You
don't want to have to declare in your API exactly what rules you will obtain,
since this exposes too many implementation details and prevent future evolution
of the implementation. The idea was to allow a client to programmatically
determine what rules will be acquired in some method, so that they could ensure
they are held before calling the method.
After writing this I'm not sure it answers the questions, but at least gives
some foundation/background.
--
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.