-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GEDF scheduler violates EDF policy #426
Comments
The GEDF only prioritizes among reactions on the same level. I think this is intended. If not it would be hard to ensure the correct semantics. There is this chain optimization which I believe should have enabled the execution of detector2 right after task2 since it is the only reaction enabled by it. So that would be a place to start looking. This is in the function |
I do suspect that this was intended, but I don't think it's the right choice. The pattern here illustrates why. Recall that a deadline specifies when a reaction should start. It is meant to be put on quick actuator reactions. It implicitly specifies completion deadlines for upstream reactions, and in fact those will have an "inferred" deadline that they automatically inherit. But notice that in this example, the upstream reaction completes on time, but the actuator fails to actuate on time because a lower priority reaction blocks it because it has a lower level. It makes the inferred deadline almost useless. The original design of the reaction queue, which GEDF disables, does ensure correct semantics and will correctly execute this program, I think. In that design, the priority is calculated first using the (inferred) deadline. Any reaction with a sooner (inferred) deadline will be ahead in the queue of any reaction with a later deadline. Then it sorts by level. This preserves semantics because all reactions upstream of a reaction with a deadline inherit its deadline (or possibly an earlier deadline if they are upstream of multiple reactions with deadlines). Hence, whole chains have the same (or earlier) deadlines, and precedences are respected. The GEDF scheduler disables this by using a distinct priority queue for each level. It also uses a distinct mutex for each of these priority queues. I can't see any advantage to this. It certainly doesn't reduce mutex contention because the levels are run in sequence. And it breaks the original intended design.
Actually, I'm not sure why this optimization in But anyway, this optimization will not solve the problem in general. If there are two downstream reactions, the optimization is not used. The original design, however, can handle this scenario. I think the right solution is to get rid of the multiple priority queues and multiple mutexes in GEDF and use one only (or more precisely, one per environment). |
I just realized that deadlines need to be inferred across federates for this to work with federated execution. I suspect that this is not currently done. But probably this should be done anyway... |
The GEDF scheduler is supposed to execute all reactions with smaller (inferred) deadline regardless of level before executing any reactions with a larger deadline or with no deadline. Unfortunately, it does not do that, as shown by the following example (due to @soyerefsane). For some reason, instead of using a single reaction queue, the GEDF scheduler uses a separate reaction queue for each level (anybody know why?). This means that it will only prioritize a reaction with a deadline over another reaction if both reactions are at the same level.
In the following program, at each tag, detetctor2 should always execute before task1. In the current realization, it never executes before task1.
Sample output:
The text was updated successfully, but these errors were encountered: