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

priority == preemptible doesn't preempt #53

Closed
nacnudus opened this Issue Jun 2, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@nacnudus
Contributor

nacnudus commented Jun 2, 2016

From ?seize:

preemptible: if the seize occurs in a preemptive resource, this parameter
establishes the minimum incoming priority that can preempt this
arrival (a seize with a priority equal to preemptible or more
gains the resource; by default, any seize may cause preemption
in a preemptive resource).

In which case I would expect the first block of code below to have the same result as the second. Have I misunderstood? I would prefer the documented behaviour, since it allows implementation of LIFO servers without needing to assign priorities.

  t0 <- create_trajectory() %>%
    seize("dummy", 1, priority = 0, preemptible = 0) %>%
    timeout(10) %>%
    release("dummy", 1)
  env <- simmer() %>%
    add_generator("p0p0:", t0, at(0, 1)) %>%
    add_resource("dummy", 1, preemptive=TRUE, preempt_order="lifo") %>%
    run()
  arrs <- env %>% get_mon_arrivals()
  arrs_ordered <- arrs[order(arrs$name),]
  arrs_ordered
#>     name start_time end_time activity_time finished replication
#> 1 p0p0:0          0       10            10     TRUE           1
#> 2 p0p0:1          1       20            10     TRUE           1
  t0 <- create_trajectory() %>%
    seize("dummy", 1, priority = 1, preemptible = 0) %>%
    timeout(10) %>%
    release("dummy", 1)
  env <- simmer() %>%
    add_generator("p1p0:", t0, at(0, 1)) %>%
    add_resource("dummy", 1, preemptive=TRUE, preempt_order="lifo") %>%
    run()
  arrs <- env %>% get_mon_arrivals()
  arrs_ordered <- arrs[order(arrs$name),]
  arrs_ordered 
#>     name start_time end_time activity_time finished replication
#> 2 p1p0:0          0       20            10     TRUE           1
#> 1 p1p0:1          1       11            10     TRUE           1

Just nitpicking really -- this is a marvellous package.

@Enchufa2

This comment has been minimized.

Member

Enchufa2 commented Jun 2, 2016

Ok, I see what's the problem: the problem is in the documentation. 😄

Suppose two arrivals with priority=preemptible=x. If preemption occurs when priority >= preemptible, then each one is able to preempt the other, and the simulator enters an infinite loop.

So I'll change the documentation to reflect that priority must be >preemptible and I'll force that, for an arrival, its preemptible parameter must be >= its priority.

@Enchufa2 Enchufa2 closed this in 82d32a4 Jun 2, 2016

@Enchufa2

This comment has been minimized.

Member

Enchufa2 commented Jun 2, 2016

New ?seize:

preemptible: if the seize occurs in a preemptive resource, this parameter establishes the minimum incoming priority that can preempt this arrival (a seize with a priority greater than 'preemptible' gains the resource). In any case, 'preemptible' must be equal or greater than 'priority', and thus only higher priority seizes can trigger the preemption.

@nacnudus

This comment has been minimized.

Contributor

nacnudus commented Jun 3, 2016

Oh right, I see. I was confused about how FIFO/LIFO was applied, and thought it was a way of implementing a FIFO/LIFO queue. But it's purely about which arrival that is already being served will be preempted.

@Enchufa2

This comment has been minimized.

Member

Enchufa2 commented Jun 3, 2016

Yeap, that's right. Because, if there are several arrivals being served, all of them with the same priority, and another one comes and triggers preemption, you need a policy to select which one should be stopped. That's the meaning of FIFO/LIFO in this context.

In any case, there was this mistake in the documentation. Thanks for the report. Keen eye! 😉

BTW, eager to read the second part of your post!

@Enchufa2 Enchufa2 added this to the v3.3.0 milestone Jun 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment