Simultaneous all-or-nothing list pulls?

[jon_abbott]

[ FlexSim 20.0.10 ]

Is there a way in FlexSim to simultaneously pull from multiple lists in a way that is all-or-nothing for the overall request? I have multiple kinds of objects that need to be chosen at the same time, or not at all if any one of them is not available to be pulled. If this kind of approach is not available with lists, is there another preferred way to model this logic? Thank you in advance for any assistance you can provide!

[jason_lightfootVL7B4]

Hi @Jon Abbott - I'm pretty sure it could be done with the Table query across multiple tables using a SQL join. Perhaps it can also be done in a subflow where a number of sibling tokens trying to pull from different lists, leave the items on the list when they succeed but whenever one of them succeeds it also forces the other tokens to check again until all of them succeed at the same time at which point they all pull and remove the items from the lists - a bit convoluted perhaps.

I asked for this feature some years ago - I'm sure it hasn't been forgotten.

[JordanLJohnson · Accepted solution]

Hi Jon, I made an example model for you. And I made it very generic so that it should work in lots of situations.

The basic idea is that I treat all the components of a request like a recipe, 2 of these, 3 of those, etc. I batch together all those components into a single request. Then, that request checks for the availability of all components. If any are missing, it waits for those components before trying again. During this phase, nothing is pulled from any list; it's just a peek.

Once the token has confirmed that all are available, it executes the next phase of the process, which is to acquire everything. Since confirmation happens all at once, the items are guaranteed to be on the lists, so the actual pull (where items are removed from the list) is guaranteed to work.

The final phase is to basically put everything back where it came from. To do that, I save the request token, and have it wait until the parent releases it.

This flow should be generic enough to use in basically any model. I will say that if you are using a SELECT statement, you'd need to modify parts of it. But this should get you going.

MultiPullExample.fsm

[jon_abbott]

Thank you @Jordan Johnson! This is tremendously helpful, and I can foresee it being used in a lot of situations where mutual resource reservation is required. One question: if a token is waiting at "Wait for Acquire" because both resources aren't available enough to meet its requirement, and another request arrives and enough resources are available for it, will that one "skip ahead" in line, or is it strictly FIFO? Thanks again for all of your help!

[jon_abbott]

Thank you @jason.lightfoot! I appreciate the suggestions.

[JordanLJohnson]

Right now, it's not strictly FIFO. A token that requires lots of resources may be blocked, while a token that requires few resources may be able acquire them and move forward. The token that requires many resources would have to wait until it could acquire all of those resources at once. So yes, tokens can skip ahead.

However, if there are multiple requests that happen simultaneously, then those tokens are ordered by their request time. The zone accomplishes this. The Zone has an option to wait for simultaneous tokens before allowing any to enter the zone. It also has an option to order those tokens. So if there happen to be multiple requests at the same (such as when many tokens are waiting on a resource, and it becomes available), those requests are ordered by age. So the oldest tokens get to check to see if they can get their resources first.

[jon_abbott]

Great, thanks again @Jordan Johnson for this very useful model and detailed write-up!