Unblocking, Threads and Attribute Gates

When Planimate moves an item out of a capacity object, say a server, the server unblocks its incoming path(s), normally in edit order. The modeller can override the unblock order (the in switch order). Once the first item moves in, the others see the server as busy and stay blocked, even though they may receive an unblock message.

Whilst a model is multi-threaded, the engine itself must be single threaded to ensure order. So its not as obviously adaptable to SMP as one might think.

Here is the fundamental item movement algorithm. Its an all or nothing, it gets executed when an item wants to try leaving an object, either because of an FEC event (delay finished) or the object has received an unblock (eg: a Queue in front of a server.

Consider a situation where A and B feed a server at C. Both A and B have items waiting to move.

C finishes and operation and does an unblock. Lets say A gets it first. A would try do a Move()

• check the target (C) is willing to accept its item (TestEnter()), assuming thats ok
• remove the item from its local capacity (LeaveObject())
• let the target object take over the item (EnterObject()) which also does the animation you see.
• Unblock all objects behind A (if any) (UnblockPrevious())

C will then get round to sending the unblock message to B. But it will be too late for B, so things will fail right up front (C wont be willing to accept the item from B and no Move() will occur)

The flow of objects involved in an all-or-nothing activity is called a thread. Change objects and switches can be part of a flow without breaking the thread whereas delay objects cannot be.

So a blocking switch between a queue and a server becomes part of the all-or-nothing move. The switch condition is ANDed with the movement logic, meaning the item will only move if the switch is "open" AND the server is available. Items cannot wait at a switch.

If a modeller implements their own movement logic (using attributes controlling blocking switches) then the modeller must ensure that the switch openings and closings occur within the same threads as the item entering and leaving the "protected" area respectively. (thats two threads there, one for entering and one for leaving. Anything can happen in between). Otherwise extra items can "slip through".

Attribute gate situations are best avoided if possible using more structured constructs like messaging, but sometimes they cannot be avoided.

---

idkbase note 69