priority == preemptible doesn't preempt

[nacnudus]

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]

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]

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]

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]

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!