Am 2013-01-11 um 19:34 schrieb Jonathan Leivent <jleivent@...>:
>> I think there is nothing you can do. Even if interrupts would get scheduled as
>> the next event, there will still be a gap if there are two or more interrupts
>> at the same time. From the perspective of the second interrupt, the
>> interrupted process has already moved on due to the handling of the first
> Are you implying that the intention is to make SimPy concurrent?
> Otherwise, what does "two or more interrupts at the same time" mean?
I think Ontje’s doesn’t mean real concurrency here, so “at the same time”
means simulation time. Two processes send an Interrupt at the same simulation
time to a third process.
> If, instead, "at the same time" is meant to refer to simulation time but
> not real time, then there is a way to fix this - make an interrupt's
> effect on a process be the next event in real time (at the same
> simulation time) by having Process.interrupt call _resume (or the
> equivalent) itself, instead of scheduling that action. Or, just do that
> if some arg like 'delay=None' or 'immediate=True' is added to the
> interrupt call, else keep the current semantics.
Until just a few days ago, interrupts were always scheduled before any other
event at the same time. We removed that prioritization to clean-up the code
a bit. Ontje also had one or two good arguments why this made logically sense.
I cannot remember them, though. ;-)
>> The semantic is like this: An interrupt will break a process as soon as
>> possible but not necessarily at the current yield statement of the process.
> Yes, that is the current semantics. I'm trying to argue for a change,
> or just an addition. Just so that interrupters that care can get the
> interrupt to break the process in precisely the state they see the
> process in when they call Process.interrupt.
I think that one of Ontje’s arguments was that this wouldn’t be possible in
real life or in a real concurrent system, so it shouldn’t be possible in
SimPy (@Ontje: Correct me if I’m wrong.).
However, I wouldn’t mind to revert to the old behavior, because it seems to
make more sense for me in this case.
>> This isn't a problem of SimPy, this is a problem of parallel programming.
>> Think of events in operating system threads. If you trigger the event, the
>> listening ones may not get woken up immediately. Maybe some other thread which
>> wasn't waiting at all is resumed before. This thread may invalidate the
> That's a very strange justification. I'm using a simulation language
> instead of directly programming what I am developing just so I can
> ignore the minutiae (mutexes, semaphores, race conditions,
> weakly-consistent memory, etc.) that come with parallel programming
> (among other things), at least for now.
>> It's application responsibility to guarantee a correct behavior. Can you try
>> to explain your problem a bit more in detail? Maybe interrupts aren't the
>> correct tool.
> One process is using a resource, and a second process wants to force the
> first one out of the resource. Similar to preemptive resource requests
> in SimPy 2.X. However, if the first process has already left the
> resource (which the first process can detect - assuming it happens
> before it tries to detect it!), then it can't handle the interrupt.
> Or, obviously, it could handle the interrupt in all cases, but that
> would make the code very ugly - there would be try blocks around all
> yields, not just those where an interrupt makes sense, in terms of the
> semantics of the simulated system. It seems to me that this is the
> approach you're arguing for - if interrupts are to be used at all, they
> might accidentally occur at any yield in the target process. So, set up
> try blocks everywhere.
> There's other alternatives as well. For instance, the first process
> could do this:
> using_resource = True
> yield resource.request()
> yield resource.release()
> using_resource = False
> yield env.timeout(0)
> except Interrupt:
> if using_resource:
> ... # resource use cleanup code
> Where that 'yield env.timeout(0)' is there just to make sure any
> interrupts directed at the resource usage are received within the try
> block. That this kludge works in all cases is far from obvious (it's
> making me a bit dizzy right now) - but it is dependent on SimPy 3 using
> FIFO scheduling for events at the same simulation time.
The extra timeout(0) is really ugly.
> So, I'm not arguing that immediate interrupts are necessary, just that
> having them would remove the need for ugliness like the above, or lots
> of try blocks, or the 'with accepting_interrupts(env) as p:' mechanism
> I mentioned in the previous e-mail.
> -- Jonathan Leivent