Alpha has to do the same thing on interrupts... the way this is handled is that there's a per-thread lock flag in the CPU that gets cleared on interrupts, and if that flag is not set then we fail the SC without even sending it to the cache. (At least that's my recollection of how it works.) Seems like ARM could/should do something similar.
Another possible way to handle these (that would be more realistic and perhaps simpler overall) would be to forward all invalidation snoops to the CPUs (which we can easily do), then have each CPU track the address it has locked (if any) and clear the lock if it sees an invalidation on the block it cares about. I think we didn't do it that way because originally we did not send snoops to the CPU, but with the current memory system it would be a minor change for M5 classic (not sure about Ruby). It would also have the benefit of eliminating the two separate LL/SC implementations in the caches and in physmem. It's also a non-trivial change that might not be worth it, and might be harder than you think it should be in Ruby. Steve On Thu, Jul 15, 2010 at 4:13 PM, Ali Saidi <sa...@umich.edu> wrote: > > ARM has an instruction that clears the lock flag (CLREX). To implement > that in physical memory, it's easy enough, on the other hand with the cache > it requires calling clearLoadLocks() on every block in the cache. > > Ali > > > > > On Thu, 15 Jul 2010 16:01:09 -0700, nathan binkert <n...@binkert.org> > wrote: >>> You're right that it could be done either way. I think the rationale >>> is that this way you don't need to search a list to see if your >>> address is on it. If the common case is that there are no locked >>> blocks in the entire cache though then that's not a big deal since the >>> list will be empty anyway. I can't think of any other reason. >> >> Why do you need a list of lock addresses? The only reason I can think >> of is because of multiple threads. Is that what you're referring to? >> I guess the other issue is that the lock address would have to be >> checked on all stores in the system which could be a pain. Another >> reason is that you're already accessing the tag for coherence >> operations, so you might as well put the lock info there. You could >> for example update MESI to have a "locked exclusive" or "locked >> modified" state. >> >> >> Nate >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
