Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Unbounded Page-Based Transactional Memory paper

0 views
Skip to first unread message

kimo

unread,
Aug 19, 2006, 2:05:40 AM8/19/06
to
This seems to be the cutting edge of Transactional Memory - it takes a
hybrid approach using concepts from both Software Transactional Memory
and a Hardware assist.

It will be presented at APLOS'06 Oct 21-25 San Jose

http://www.cse.ucsd.edu/~calder/papers/ASPLOS-06-PTM.pdf

Chris Thomasson

unread,
Aug 19, 2006, 4:57:52 PM8/19/06
to
"kimo" <kimocr...@gmail.com> wrote in message
news:1155967540.1...@m79g2000cwm.googlegroups.com...

It seems like there would be some overhead wrt keeping the "home page"
synchronized with its "shadow page". I am not too sure how well this would
scale with large linked data-structures:

My main problem with TM is that reader threads have to call into the
transaction api before they traverse a data-structure. In most cases every
read has to be tracked; validating at the page-level is too coarse. If they
end up traversing tens-of-thousands of nodes, that's a lot of
checking/validating. If the application is under load, and writer threads
modify the page of memory that a reader thread happens to be reading from
seems to raise a red-flag in the presented algorithm. Then the validation
process has to drill down on the page, to enhance transaction granularity.
If alls that it takes is a simple store into the page to abort a
transaction, then live-lock can and should occur... So they have to get more
fine grain than a page...

Cache-coherency protocol deals with transaction that fit into cache line...
Humm, this may make the protocol too complex/strong. I am to a big fan of
extremely strong cache.

I need to look at this some more...


Chris Thomasson

unread,
Aug 19, 2006, 5:29:50 PM8/19/06
to
Ooops:

> Cache-coherency protocol deals with transaction that fit into cache
> line... Humm, this may make the protocol too complex/strong.


>I am to a big fan of extremely strong cache.

^^^^^^^^^^^^^


I am NOT a big fan of "extremely" strong cache.


0 new messages