Enforce an invariant for resource queues

#50 Merged at 1b5ee14
Repository
simpy-issue-62
Branch
default
Repository
simpy
Branch
default
Author
  1. Ontje Lünsdorf
Reviewers
Description

This PR removes immediately triggered requests also immediately from resource queues. In current simpy master this happens later, once the request gets processed, which causes inconsistencies as reported in issue #62.

We require only a very limited interface from resource queues, what makes the removal somewhat difficult. I chose to change the interface by adding __len__() and pop() and removing the costly remove(). All existing queue implementations are based on list so that doesn't matter in simpy's code.

Suggestions for keeping the old interface are welcome. If there aren't any, I vote for merge.

Comments (8)

  1. Wim Vancroonenburg

    Hi leunsdorf,

    Concerning issue #62, i'm not sure this pull request solves my 'issue' . Is it intended behavior that a resource request that is immediately fulfill-able, is granted before the request is yielded ?

    1. Stefan Scherfke

      Now that you bring that up, I think I remember that we already implemented the behavior of Ontje's PR in an older version of SimPy and fixed to the current behavior. However, I can’t remember why we did it. But maybe I’m wrong.

    2. Ontje Lünsdorf author

      Yielding simply means to wait for the event to happen. You can also wait for events that have already been triggered long ago.

      Do you expect the request should be executed only if it has been yielded?

      1. Wim Vancroonenburg

        I interpreted it differently. My expectation was that the request event was yielded to the environment and would return when it could be accommodated. However as you now explain it, the semantics of the yield is more like joining with a Thread (I have java background). This behavior seems equally valid, it's just not what I expected. But knowing this, I can work around it.

        1. Ontje Lünsdorf author

          I see. I think the closest match in the java world are futures. I think value = yield evt would almost be semantically identical to Object value = future.get(); (except of course, yield will not block the current thread).

          I assume the discussion is favorable for the PR, so far. If Stefan doesn't find the revision and nobody speaks up, I'll merge later this week.