On Fri, Dec 24, 2010 at 7:01 PM, nathan binkert <[email protected]> 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. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
