On Tue, Jan 4, 2011 at 5:56 PM, nathan binkert <n...@binkert.org> wrote:
> 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? > It's a flexibility/fear-of-commitment thing... initially I wasn't positive which way I would go, and once I decided that curTick-as-EventQueue/Manager-field wasn't going to work well (too many places where it's pretty awkward to find the object pointer), I figured it would still be useful in case we need to use pthread_setspecific/getspecific on some platforms (OS X? OpenBSD? Cygwin?). I also kind of like how it indicates that curTick is not a "normal" variable... implicitly declaring it as part of TLS in one file without any indication at each reference that it's different seems potentially confusing. > This seems to mean that I shouldn't have created the whole EventManager > thing and had schedule be a per-object thing. > Why do you say that? Because you could put the EventQueue pointer in TLS too and not do the object-based lookup? I think it would be useful to check that the EventManager queue pointer and the TLS queue pointer are the same. > TLS scares me, but maybe that's unnecessarily. :) > Why? > 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. > I haven't gotten that far yet, but yes, something like the locked external queue with async polling was what I was thinking of so far. I've been approaching it more top-down: what should simulate() look like, how do we do initialization, etc. > Anyway, I've thought about this a lot. Happy to do a phone call if you > want. > Sure, I've got some time today late morning & early afternoon if you're free. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
