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

["Rubén Titos" <rtitos@xxxxxxxxxxx>]

Jayaram 

Thanks for your quick response. 

I'm not simulating instruction fetches so far. I tried to follow the LL approach and immediately abort the transaction, yet this does not seem to avoid the code following the transaction to be executed (I still got a call to beginTransaction from the aborting processor). Perhaps I didn't do it correctly? I just copy-n-pasted the code from abortLazyTransaction into my notifyCommitNackReceived function, right under "enable_simics_proc" (disabled at the beginning of this "commit request" message exchange) and "beginEscapeAction"  (to emulate what's done in trapToHandler so that restartTransaction does not complain). Even if I got it to work in this way, this kind of non-sw-handler abort would be simulated as taking zero cycles to restore the log, wouldn't it? Which is not exactly true... So, for now, I think I'm going to try simulating IFETCH's, and see if that way the trap kicks in before "anything else" is executed.

Thanks again for your prompt response,

Ruben

On Fri, Apr 25, 2008 at 9:36 PM, Jayaram Bobba <bobba@xxxxxxxxxxx> wrote:

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.
>
>

_______________________________________________
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.

-- 
Rubén Titos
Parallel Computing and Architecture Group
Computer Engineering Dept.
University of Murcia
http://skywalker.inf.um.es/~rtitos/