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

[Luke Yen <lyen@xxxxxxxxxxx>]

   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.