Re: [Gems-users] How to abort a transaction at commit time

[Jayaram Bobba <bobba@xxxxxxxxxxx>]

Ruben,

The LL systems have a similar issue. They might have to abort after 
reaching the COMMIT instruction
if they dont receive the commit token and a conflicting invalidation 
comes in while they are stalled for the
commit token.

commitTransaction() in TransactionInterfaceManager.C has code that 
handles this case. In this case,
we instantaneously abort the transaction at commit point and post a 
simics callback for restarting it.
I think the callback is given before the next instruction is fetched and 
we end up restarting the execution.
I am not sure since its been some time since I looked at this behaviour.

In your case, I think the abort trap should be raised before SIMICS 
retires the next instruction fetch.
Are you simulating instruction fetches too? Look at canRetireMemRef() 
code in TransactionSimicsProcessor.C
to determine why Ruby is allowing SIMICS to 'execute' the next 
instruction. I guess the right behavior is to not
allow this to happen...

Jayaram

Rubén Titos wrote:
> Dear list,
>
> I'm simulating a LogTM-like (EagerCD EagerVM) transactional memory 
> machine, using GEMS 2.0 and simics 2.2.19. <http://2.2.19.>
> I've customized the filter_directory protocol and 
> TransactionInterfaceManager.C so that a commit_transaction 
> "instruction" has to notify each L2 bank, and must receive a 
> commit_ack msg before the commit actions actually take place. I 
> managed to do that without much problem, just disabling the simics 
> processor when executing 
> TransactionInterfaceManager::commitTransaction, and enabling it again 
> when all the commit_acks have arrived (calling xact_mgr from the 
> protocol).
> However, now I want to go one step further and want to add 
> "commit_nack" messages that, instead of "granting commit", force the 
> transaction to abort. Here is where I'm having trouble:  I can't 
> prevent the transaction from continuing its execution PAST the commit 
> magic call before the abort happens. After all the commits acks/nacks 
> have arrived, my "notifyCommitNackReceived" call  does find shouldTrap 
> set to true (setAbortFlag is called earlier, by some other code of 
> mine) but the question is, how can I abort that transaction at that 
> time? If I just enable the simics proc (as I did before, when I had 
> only acks) , it eventually traps after executing the next instruction, 
> but that is not only semantically incorrect but sometimes also leads 
> to new calls to beginTransaction by the (to-be) aborting processor, 
> before the abort trap actually jumps in.
> So, can anybody help me on how to abort a transaction after simics has 
> reached the commit PC?
> Thanks in advance,
>
> Ruben
>
> --
> Rubén Titos
> Parallel Computing and Architecture Group
> Computer Engineering Dept.
> University of Murcia
> http://skywalker.inf.um.es/~rtitos/ 
> <http://skywalker.inf.um.es/%7Ertitos/>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>