Reneging customers

[Enchufa2]

Linked with #49. Thanks to @nacnudus. From here,

Reneging (or, better, abandonment) occurs if an impatient customer gives up while still waiting and before being served.

[Enchufa2]

Idea:

t <- create_trajectory() %>%
  # renege in 5 min. if nothing prevents it
  renege_in(5) %>%
  seize("resource", 1) %>%
  # the arrival has seized the resource in time, aborting
  renege_abort() %>%
  timeout(1) %>%
  release("resource", 1)

A problem with this: it could be interesting to do something else if reneging is triggered. How? Adding a secondary trajectory as an optional argument of renege_in()?

[nacnudus]

Perhaps reneging can be thought of as a kind of branch that is aware of the outcome of seize().

[Enchufa2]

You mean a kind of ifseize (#49)? I thought the same at first, since both features represent similar behaviours. But note that they are conceptually very different: #49 depends on the resource status, while reneging depends entirely on an arrival's decision. So I have this feeling that this feature should be implemented in a completely different way.

And a proposal like renege_in, renege_abort would go beyond the functionality supported by SimPy, because it would allow the arrival to renege at any time, even after successfully seizing the resource. Why not? Suppose you are at the bank and you are attended after a long wait, and the operation you are going to do will take a while too. But maybe you have other urgent matters, and you may decide to renege anyway because... the supermarket is going to close, for instance.

[nacnudus]

I do mean a kind of ifseize, but the difference is that reneging occurs before the outcome of ifseize is determined.

My understanding is that an arrival will only renege before progressing from queue to server, or during service, so reneging from the queue depends on the resource status as well as the arrival's decision. If the resource accepts the arrival soon enough, then they won't renege. Reneging during service (your supermarket example) would be a separate reneging step, and could be implemented with the existing timeout() and an attribute to flag whether they completed service or not.

[Enchufa2]

I do mean a kind of ifseize, but the difference is that reneging occurs before the outcome of ifseize is determined.

The other way around: reneging occurs after the outcom of ifseize. This outcome is determined by the resource status. If there is room, the ifseize resolves that the arrival is accepted. And then, while waiting in queue, the arrival may decide to renege. But if there is no room and ifseize resolves to reject the arrival, reneging won't occur.

so reneging from the queue depends on the resource status as well as the arrival's decision.

I don't see how it depends on the resource status at all. If the server accepts the arrival soon enough, then the arrival decides not to renege.

[nacnudus]

I think the source of the confusion is that the seize or ifseize steps control both the acceptance of an arrival into the queue, and also the time that service begins. My understanding of reneging is that it takes place between those two events. The time of the second event is only determined when a server becomes available, which is what I mean by "depends on the resource status". That is, the "server" part of the resource.

There's also a reverse dependency of the "queue" part of the resource on the time that an arrival reneges. In a full, finite queue, when an arrival in the queue reneges, there is then room to accept another arrival. In that case, the server doesn't get "seized" at all, because the arrival has reneged, so in that sense I meant "reneging occurs before the outcome of ifseize is determined".

This is becoming quite a general discussion. Would it be more appropriate in the discussion forum? I also feel like I'm muscling in on your project!

[Enchufa2]

I think the source of the confusion is that the seize or ifseize steps control both the acceptance of an arrival into the queue, and also the time that service begins.

As I said in the other thread, they control only the acceptance of an arrival to the resource. If it's accepted and goes into the queue, the trajectory is suspended. Then, the resource is autonomous managing the transition from queue to server, and reactivates the trajectory by doing so. Therefore, reneging occurs after a seize is executed, but the trajectory is suspended until the arrival goes into the server.

There's also a reverse dependency of the "queue" part of the resource on the time that an arrival reneges. In a full, finite queue, when an arrival in the queue reneges, there is then room to accept another arrival. In that case, the server doesn't get "seized" at all, because the arrival has reneged, so in that sense I meant "reneging occurs before the outcome of ifseize is determined".

Ok, I follow what you mean. But still, the arrival takes the decision and informs the resource, "ok, I waited too much, I'm leaving".

From the implementation point of view, there should be a process dedicated to trigger the action of reneging after a timeout. I think you propose to launch this process from seize (and ifseize), which requires to complicate its syntax (and it's not short right now). I propose to define another activity for this purpose.

This is becoming quite a general discussion. Would it be more appropriate in the discussion forum?

Maybe yes, since we are discussing more about concepts, definitions and so on. 😄 I would keep this thread to propose concrete syntaxes, as in my second comment, and discuss their appropriateness in terms of performance and intuitiveness.

I also feel like I'm muscling in on your project!

Not at all. Every single discussion I engaged about simmer has resulted in awesome ideas and features. So keep pushing forward!