-
-
Notifications
You must be signed in to change notification settings - Fork 42
add preemption functionality #34
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
Comments
👍 Comments inline:
First of all, the resource needs to support preemption. I mean, I would create a flag in env <- simmer() %>%
add_resource("CPU", preemptive=TRUE) Said that, I don't know if it is fair that any arrival can be preempted (debatable). I'm thinking about an operating system: some kernel tasks are not preemptible. In this scenario, the preemption depends on the task being served, not on the arriving one. So what if we define an attribute
The scenario between parentheses cannot happen, because the preemption has been triggered by B and these steps occur instantaneously.
If we implement A as
It could be another argument for task <- create_trajectory() %>%
seize("CPU", priority=1, preemptible=TRUE, restart=FALSE) %>%
timeout(function() runif(1, 5, 10)) %>%
release("CPU") |
Another issue. Suppose the following: task0 <- create_trajectory() %>%
seize("CPU", 1, priority=0, preemptible=TRUE) %>%
timeout(10) %>%
release("CPU", 1)
task1 <- create_trajectory() %>%
seize("CPU", 1, priority=1) %>%
timeout(10) %>%
release("CPU", 1)
env <- simmer() %>%
add_resource("CPU", 2, preemptive=TRUE) %>%
add_generator("low_priority", task0, at(0, 1)) %>%
add_generator("high_priority", task1, at(2)) %>%
run() When the high priority task arrives at 2, which task should be postponed? |
Completely agree.
This is a tricky one I guess. I'm reasoning the other way around. What if you have an ER with n types of patients (each their own trajectory) but only 1 type of patient (e.g. severe trauma) can preempt a resource. If you would want to simulate this using your suggestion, you should set n-1 trajectories' seize activity to preemtible. I guess the question is: in what scenario would the simulator most likely find himself?
Good point. What if B requires two units of resource Y, while A has seized 1 unit and C has seized 1 unit (assuming A and C are preemptible)?
Indeed!
Agree, making it a choice allows for the most flexibility. |
Well, this is a kind of philosophical question. 😄 If I would want to simulate your use case with my suggestion, the But what if you want to simulate my use case with your suggestion? 😉
Easy. A and C are preemptible, so both are preempted at the same time in favour of B. More challenging is the question of my last comment: #34 (comment). |
I agree that your suggestion would allow for more flexibility. As an in-between solution, maybe we could set
Agree
Regarding #34 (comment); I would say the arrival that started processing last. But I guess there aren't any strict rules for this and it comes down on us making a decision 😉 |
Agree.
Again, this is a sort of philosophical question. Maybe I would preempt:
What do you think? |
👍
Pff. This is difficult. What if being preempted means starting over again? If so, it would make more sense that the last one in gets preempted (as he has less to lose). What about going the FIFO route for now and possibly make it a choice later one? |
Touché. What if we make env <- simmer() %>%
add_resource("CPU", preemptive=TRUE, restart=FALSE) Then |
👍
Whether or not there is a restart could potentially be defined in the seize: #34 (comment). I would suggest adding a |
👍 |
Let's use this for further discussion on the preemption topic.
Maybe we should start with trying to settle on a definition, a suggestion:
The text was updated successfully, but these errors were encountered: