Problem in acquire resource order

Question

question

Patrick Zweekhorst asked Jan 31, '18 Patrick Zweekhorst commented Feb 12, '18

Problem in acquire resource order

Hi All,

I have a small problem with the order in which some tokens acquire a resource. Let me try to describe the situation:

The resource is claimed by token1. After some time token2 also wants to acquire that resource. Token2 is therefore now a backorder for the resource. Some time later the resource is released by token1. Directly after this token1 tries to acquire the resource again (so at the same time). I would expect that token2 now continues since that token was already in the acquire resource. This is however not the case. Somehow token1 is able to acquire the resource again.

In both acquires I have a (useless in this example) query. I found out that if I do not have those queries it works as I would expect, token2 continues in that case.

You can see both situations in the attached example model. Note how the two parts become different after time 22. Also note that I have enabled the Allow multiple pushes before back order fulfillment, since I need that option in my actual model.

Is this a bug that can be fixed in the next release? If someone knows a work around for this problem I would really appreciatie that. I tried to do something with back order queue strategy, but I was unable to solve this problem.

Thanks in advance,

Patrick Zweekhorst

acquireresourceproblem.fsm

Software Version:

FlexSim 18.0.2

acquire resource fifo

acquireresourceproblem.fsm (33.4 KiB)

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 1 · 2018-02-05T18:20:10Z

Matt Long answered Feb 5, '18 Patrick Zweekhorst commented Feb 12, '18

This is not a bug and is working as intended. The short answer is that the Resource with a query is using a List behind the scenes to handle the query and back orders. The Resource without a query does not use a list.

The reason you're seeing the behavior you're seeing has to do with how you have setup your List that the Resource uses in order to evaluate the queries. You checked the box "Allow Multiple Pushes Before Back Order Fulfillment" in the Resource's List properties. This setting causes a back order fulfillment event to be created in 0 time once something is pushed to the list (the resource is released). Since there is no delay between the Release and Acquire activities, the token attempts to acquire a resource and is given one as one is available. The back order fulfillment event doesn't fire until that token has already left the acquire and is sitting on the following delay activity. At which point there is nothing for the 2nd token to acquire. If you open up the Event List you can see what I'm talking about.

Please refer to the Back Orders Tab documentation for more information on the "Allow Multiple Pushes Before Back Order Fulfillment" property. Uncheck this box and it works the way you want it to.

As for the breathe (delay for 0 time) doesn't work between the Release and Acquire activities is because the back order fullfillment event ensures that if multiple pushes are done by multiple events all at the same time, they are all pushed onto the list before the back orders are evaluated. Setting your breathe to be 0.00001 will work.

· 5

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Matthew Gillespie ♦♦ commented · Feb 05, 2018 at 07:09 PM

If you switch over to using lists you'll get the behavior you're looking for. A Push to List activity will wait until the thing it pushed on the list is pulled, whereas a Release Resource immediately moves on.

listvsresource.fsm

0 ·

listvsresource.fsm (34.1 KiB)

Patrick Zweekhorst Matthew Gillespie ♦♦ commented · Feb 06, 2018 at 08:20 AM

Hi @Matthew Gillespie ,

Thank you for your suggestion. This will indeed help in some situations. It is however possible that token2 from my example does not exists. In that case token1 will stay in the push to list activity and will never continue. This can of course be fixed by adding a max wait timer, but in that case we are back at the original problem.

0 ·

Patrick Zweekhorst commented · Feb 06, 2018 at 08:17 AM

@Matt Long ,

Thank you for your long answer. Unchecking the "Allow Multiple Pushes Before Back Order Fulfillment" property will work the way I want in this small example model. In my actual model I do however want to use that property for ordering the resources that could be acquired. Multiple resources could be released at the same time and I do not always want the back order to be fulfilled by the first resource that is released. That is the reason I checked the property.

But as I understand this property will not work in combination with the situation I described above?

Adding a delay of 0.00001 is also not completely what I want. In the actual model I have a back order queue strategy. This because it is also possible that token1 from my example has priority over token2. You will not see this if I include a small delay, since that will mean that the back order of token2 will be fulfilled before token1 enters the acquire resource activity.

Is there some setting such that I can use the "Allow Multiple Pushes Before Back Order Fulfillment" property in combination with a back order queue strategy?

0 ·

Matthew Gillespie ♦♦ Patrick Zweekhorst commented · Feb 09, 2018 at 09:09 PM

We're looking into changing the list logic to make this work more intuitively. But for now, you should use a Split activity such that token 1 tries to acquire the resource and then the split off child token can release the resource. This way both tokens have a back order on the list when the resource is released.

acquirethenrelease.fsm

0 ·

acquirethenrelease.fsm (40.3 KiB)

Patrick Zweekhorst Matthew Gillespie ♦♦ commented · Feb 12, 2018 at 01:20 PM

Hi @Matthew Gillespie ,

Thank you for this solution. I think this will help in my model.

0 ·

question