DOC PREVIEW
U of U CS 7810 - Lecture 6 - TM – Eager Implementations

This preview shows page 1-2-3-4-5-6 out of 18 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Lecture 6: TM – Eager Implementations• Topics: Eager conflict detection (LogTM), TM pathologies2Design Space• Data Versioning Eager: based on an undo log Lazy: based on a write bufferTypically, versioning is done in cache;The above two are variants that handle overflow• Conflict Detection Optimistic detection: check for conflicts at commit time(proceed optimistically thru transaction) Pessimistic detection: every read/write checks forconflicts (so you can abort quickly)3“Eager” OverviewTopics:• Logs• Log optimization• Conflict examples• Handling deadlocks• Sticky scenarios• Aborts/commits/parallelismCDirPR WCDirPR WCDirPR WCDirPR WScalable Non-broadcast Interconnect4“Eager” Implementation (Based Primarily on LogTM)• A write is made permanent immediately (we do not waituntil the end of the transaction)• Can’t lose the old value (in case this transaction isaborted) – hence, before the write, we copy the oldvalue into a log (the log is some space in virtual memory-- the log itself may be in cache, so not too expensive)This is eager versioning5Versioning• Every overflowed write first requires a read and a write tolog the old value – the log is maintained in virtual memoryand will likely be found in cache • Aborts are uncommon – typically only when thecontention manager kicks in on a potential deadlock; thelogs are walked through in reverse order• If a block is already marked as being logged (wr-set), thenext write by that transaction can avoid the re-log• Log writes can be placed in a write buffer to reducecontention for L1 cache ports6Conflict Detection and Resolution• Since Transaction-A’s writes are made permanentrightaway, it is possible that another Transaction-B’srd/wr miss is re-directed to Tr-A• At this point, we detect a conflict (neither transaction hasreached its end, hence, eager conflict detection): twotransactions handling the same cache line and at leastone of them does a write• One solution: requester stalls: Tr-A sends a NACK toTr-B; Tr-B waits and re-tries again; hopefully, Tr-A hascommitted and can hand off the latest cache line to B neither transaction needs to abort7Deadlocks• Can lead to deadlocks: each transaction is waiting for theother to finish• Need a separate (hw/sw) contention manager to detectsuch deadlocks and force one of them to abortTr-A Tr-Bwrite X write Y… …read Y read X• Alternatively, every transaction maintains an “age” and a youngtransaction aborts and re-starts if it is keeping an older transactionwaiting and itself receives a nack from an older transaction8Block Replacement• If a block in a transaction’s rd/wr-set is evicted, the datais written back to memory if necessary, but the directorycontinues to maintain a “sticky” pointer to that node(subsequent requests have to confirm that the transactionhas committed before proceeding)• The sticky pointers are lazily removed over time (commitscontinue to be fast); if a transaction receives a request fora block that is not in its cache and if the transaction hasnot overflowed, then we know that the sticky pointer canbe removed9Paper on TM Pathologies (ISCA’08)• LL: lazy versioning, lazy conflict detection, committingtransaction wins conflicts• EL: lazy versioning, eager conflict detection, requestersucceeds and others abort• EE: eager versioning, eager conflict detection, requesterstalls10• Two conflicting transactions thatkeep aborting each other• Can do exponential back-off tohandle livelock• Fixable by doing requester stalls? Anything else?• VM: any• CD: eager• CR: requester winsPathology 1: Friendly Fire11• A writer has to wait for the readerto finish – but if more readers keepshowing up, the writer is starved (note that the directory allows newreaders to proceed by just addingthem to the list of sharers)• VM: any• CD: eager• CR: requester stallsPathology 2: Starving Writer12• If there’s a single commit token,transaction commit is serialized• There are ways to alleviate this problem• VM: lazy• CD: lazy• CR: anyPathology 3: Serialized Commit13• A transaction is stalling on anothertransaction that ultimately aborts andtakes a while to reinstate old values• VM: any• CD: eager• CR: requester stallsPathology 4: Futile Stall14• Small successful transactions cankeep aborting a large transaction• The large transaction can eventuallygrab the token and not release ituntil after it commits• VM: lazy• CD: lazy• CR: committer winsPathology 5: Starving Elder15• A number of similar (conflicting)transactions execute together – onewins, the others all abort – shortly,these transactions all return andrepeat the process• VM: lazy• CD: lazy• CR: committer winsPathology 6: Restart Convoy16• If two transactions both read thesame object and then both decide towrite it, a deadlock is created• Exacerbated by the Futile Stall pathology• Solution?• VM: eager• CD: eager• CR: requester stallsPathology 7: Dueling Upgrades17Four Extensions• Predictor: predict if the read will soon be followed by awrite and acquire write permissions aggressively• Hybrid: if a transaction believes it is a Starving Writer, itcan force other readers to abort; for everything else, userequester stalls• Timestamp: In the EL case, requester wins only if it is theolder transaction (handles Friendly Fire pathology)• Backoff: in the LL case, aborting transactions invokeexponential back-off to prevent convoy formation18Title•


View Full Document

U of U CS 7810 - Lecture 6 - TM – Eager Implementations

Download Lecture 6 - TM – Eager Implementations
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 6 - TM – Eager Implementations and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 6 - TM – Eager Implementations 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?