Re: [Gems-users] Non-stallable requests and transactional protocols

[Kevin Moore <kmoore@xxxxxxxxxxx>]

Enrique,
	You're right, that could certainly pose a problem for 
transactional requests.  I think we could use the 'fast 
path' code (see Sequencer.C) if the access is a cache hit. 
But, I'm not sure how to best handle cache misses since they 
might be transaction conflicts.  In general, we've tried (so 
far) to avoid using locks inside transactions.  But, it 
would certainly be nice to have a better solution.
--Kevin

Enrique Vallejo Gutierrez wrote:
> Dear List,
>
>  
>
>       I have been making some changes to Ruby on the LogTM protocols, 
> and I have found a problem that might also affect the original protocol 
> in some corner cases. When a *non-stallable memory operation* is 
> executed (such as a casxa, swap or ldda instruction), the 
> mem_trans->s.may_stall bit is set to 0 by Simics. This means that the 
> timing model (Ruby) is not allowed to model the timing of the request, 
> it is directly executed. This case is considered in 
> SimicsDriver::isUnhandledTransaction().
>  
>
>       This is not a serious problem in ordinary protocols, as the global 
> image view of the memory makes the operation coherent (given that cache 
> data is not modelled). However, in transactional protocols, this becomes 
> quite a serious concern, as *the possible collisions or the log entries 
> that would be generated by the access are not considered*. This would 
> mean, for example, that an aborting transaction would not restore the 
> original value of the line modified by the casxa instruction. I know 
> this is a corner case, but it migh affect, for example, to code that 
> acquires and releases locks in the middle of a transaction.
>  
>
>       This is clearly a limitation of Simics, not Ruby, that does not 
> allow stalling certain memory transactions. Anyway, has someone ever 
> experienced a similar situation and can give some hints on how to avoid 
> the problem? I would really appreciate some help with the problem.
>  
>
>       Thanks in advance,
>
>  
>
> Enrique Vallejo
>
> University of Cantabria, Spain
>
> http://www.atc.unican.es/~enrique/
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.