> > I want to keep this a purely syntactic change, because I think the semantic > changes are going to require some discussion. For example, my current > next-step patch replaces mainEventQueue with an array of queues (so there is > no single main event queue any more), and uses TLS to implement per-thread > curTick values rather than embedding them in the queues, so it doesn't follow > the path you're proposing. If you want to discuss this further please start > a new email thread. > > The good news is that once this patch gets committed then all these options > can be explored with fairly local changes. > > Interesting. If you were going to do this, why do you need accessors at all? This seems to mean that I shouldn't have created the whole EventManager thing and had schedule be a per-object thing. TLS scares me, but maybe that's unnecessarily. :) How were you planning on having thread 1 schedule an event on thread 2's eventq? Were you going to use some sort of FIFO between threads? One per eventq with a lock only on the producer side, or one lock-free per pair of threads? (I assume the former. I have code somewhere for the latter that I wrote a long time ago.) Further assuming that the FIFO is a yes, how were you going to check it? Polling it periodically? Seems that this could all be rolled into the whole async wrapper around the event queue.
Anyway, I've thought about this a lot. Happy to do a phone call if you want. Nate
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
