Citation Context

...that after setting a specific schedule new conflicts appear or the program execution serializes. 3.3 Checkpoints Various mechanisms have been proposed to implicitly checkpoint transactions at runtime =-=[3, 37]-=-. If a checkpointed transaction aborts, it is rolled back up to the earliest valid checkpoint. Checkpoints can improve the performance of transactional applications because (i) the transaction is not ...

Citation Context

...che coherence protocol as in DATM [18] or in non-trivial bookeeping requirements to ensure correct ordering as in SONTM [2]. Other proposals involve a “state correcting” step. Specifically, in RetCon =-=[4]-=-, execution proceeds after a data conflict occurs. However, when the chunk is ready to commit, RetCon attempts to fix its state by obtaining the current value of the variables that were involved in th...

Citation Context

... transactions consecutively abort each other which particularly occurs in Genome. As the impact of this technique can be significant, we profiled the applications and tuned the mechanism such that performance and not the abort rate is optimized. Without exponential backoff 2PL and CS show even higher abort rates and consequently lower performance. 7. Related Work The importance of reducing aborts in transactional memory systems has been emphasized before and addressed using different approaches. Bobba et al. [10] determine certain pathologies that can lead to high abort rates. Blundell et al. [8] propose to commit transactions even in the case of read-write conflicts by repairing (re-executing reads to obtain the current version) transactions instead of replaying transactions entirely. Their approach does not apply to arbitrary conflicts but only to “non critical conflicts” occurring on auxiliary or bookkeeping data. Waliullah et al. [56] propose to detect and ignore non critical conflicts including false sharing, silent stores and write-write conflicts without intermittent reads. Improving TM performance by reducing the number of aborts has been addressed by Ansari et al. using trans...

Citation Context

...s described in Section 6). Repeated aborts limit speedup (column “S”) and force many transactions to acquire a global lock and revert to irrevocable mode (column “%I”) in order to make forward progress. A high ratio of cycles spent in aborted transactions relative to committed transactions (“W/U” column) correlates strongly with energy waste. As shown in the final, vacation row, wasted work can still be significant even in programs with reasonable speedup. Several previous projects have proposed hardware mechanisms to reduce the incidence of conflict aborts. Examples include DATM [21], RETCON [3], Wait-n-GoTM [14], and OmniOrder [20]. While these proposals achieve nontrivial improvements in abort rates and system throughput, they suffer from several limitations. First, most entail significant new hardware complexity—e.g., for the transactional-cycle detector of Wait-n-GoTM or the 8 new coherence protocol states of DATM. Second, they tend to target specific patterns of contention—e.g., the simple conflicting code slices of RETCON or the circular dependences of DATM and Waitn-GOTM; they may miss other opportunities. Third, they are often specific to particular styles of HTM—e.g., lazy f...

Citation Context

... handle this case was still required. This was the main disadvantage to the DATM proposal, its 30 complicated hardware to track dependencies and major coherence changes. A proposal by Blundell et al. =-=[34]-=- called RetCon also tackled the problem of ancillary updates that cause what can be considered false conflicts. Instead of making large changes to the coherence scheme and adding tracking data structu...

Citation Context

... switch in our system. Note that after stalling, the transaction is not guaranteed to execute as a new abort could be predicted. This transaction size threshold allows for at least two consecutive stalls before having a penalty larger than yielding. We use the STAMP [8] benchmark suite with nine different benchmark configurations. Figure 9 describes the input parameters used and the number of transactions defined in each benchmark. We exclude Bayes because of its non-deterministic exiting conditions, leading to inconclusive results due to high runtime variability, as noted by many researchers [3, 6, 8]. B. Comparison of Hardware Costs Figure 10 shows the storage requirements for HARP and BFGTS. Implementing HARP requires an additional storage of 2.06KB on each core, roughly 3% of a 64KB L1 cache. HARP requires less storage than BFGTS. This is because BFGTS uses an additional 2KB cache to speedup accesses to its software data structures. Moreover, a cache needs additional logic (e.g, tags), not considered in this comparison. C. Evaluation Methodology Our evaluation includes three different system setups: (a) a setup with a single-application using the same number of threads as cores, (b) a s...

Citation Context

... either of them can be eager or lazy independently. Alternative strategies are also possible. Based on the observation that conflicts often happen effect a small part of the transaction code, RETCON (=-=Blundell et al., 2010-=-) repairs the conflicting part at commit time so the re-execution of entire transaction can be avoided. Instead of relying on abort mechanism to resolve conflict, Wait-n-GoTM (Jafri et al., 2013) prev...

Citation Context

...al code [93], different bufferingsand conflict detection strategies [94], partial transaction commit to avoid wasted work [95], partialsre-execution to avoid the need to perform rollback on conflicts =-=[96]-=-, and hybrid hardware-softwaressupport for transactions [97]. HTM techniques have also been repurposed to accelerate lock-basedscritical sections by speculatively eliding lock acquisition [70], to san...