Re: [Gems-users] A tricky design of delay restarting an aborted transaction in LogTM

[郭锐 <timmyguo@xxxxxxxxxxxxxxxx>]

Thanks for you explanation. But I think this design doesn't help solving the
starving problem 
but may help decreasing the number of nack/retry.
Do I miss something?
G.R.

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx]
> On Behalf Of Luke Yen
> Sent: Monday, January 22, 2007 11:54 PM
> To: gems-users@xxxxxxxxxxx
> Subject: Re: [Gems-users] A tricky design of delay restarting an aborted
> transaction in LogTM
> 
> 
>    You are correct that this is an unimplementable solution.  The reason
> for this is that we have seen pathological cases where many readers were
> starving a writer because readers would have cache hits on their
> transactional accesses while the writer would have to do work to
> invalidate the readers.  At the time of the release we were not concerened
> with these effects, so we implemented oracle waiting.
> 
>   Some other alternatives that we have implemented in the past include
> cache coherence protocol changes and adding exponential backoff for
> processors that expererienced transaction aborts.
> 
>   Luke
> 
> ===================================
> When an aborted transaction is restarted, the LogTM implementation checks
> against the remote transaction that caused the abort. Only when the
> conflicting transaction is done, the newly restarted transaction would
> stall
> until the conflicting one completed (committed or aborted).
> This check is done by comparing the timestamp of the conflicting *xact
> manager* with that of the conflicting response (that NACK response).
> 
> Now, the problem comes up: how can a xact manager query a remote xact
> manager without any latency in a real world? That would be oracle, or
> nonsense.
> 
> G.R.
> _______________________________________________
> 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.