On Dec 26, 2010, at 10:40 PM, Steve Reinhardt wrote: > > > On Fri, Dec 24, 2010 at 7:01 PM, nathan binkert <n...@binkert.org> wrote: > > I'm wondering why we need to dynamically allocate this object at all... the > > only benefit I see is that in theory, we could have multiple disjoint parts > > of the system draining concurrently but with independent completion > > detection. In reality, I don't see how we would really do that, unless we > > had multiple python threads calling the python drain() function > > concurrently, which doesn't seem likely to happen in our lifetimes. > > Is anyone opposed to just using a global variable for the drain counter, and > > a global function to decrement it and exit the sim loop when it hits zero? > > I don't think a global variable will work because if you have two > systems, they may not drain at the same time. I think that a drain > count on the system object could work fine though. > > That's what I was referring to... you can indeed have different parts of the > config (e.g., different systems) draining at different times, but that's > compatible with a global variable as long as those independent drain > operations don't overlap in time. That is, the global variable can be used > by just a subset of the config, the only constraint is that you can only have > one drain operation in process at a time. Given that the python drain() > function doesn't return until the drain operation is complete, it's not even > possible to express multiple concurrent drain operations in a script right > now. Even if it were expressible, I cannot envision a scenario where it > would be useful. Thus I'm thinking that the current setup is overkill.
Why not just have a drain object be part of the System class? It seems like that should solve the problem and allow to concurrent drain events to occur if we decided that functionality was required at some point. Ali
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
