60 likes | 272 Views
Networked Software Systems Lab Department of Electrical Engineering, Technion. Analyzing Aborts in Software Transactional Memory. Submitted by: Omer & Ofer Kiselov Supevised by: Dmitri Perelman. Transactional Memory and Aborts. Transactional Memory solution
E N D
Networked Software Systems Lab Department of Electrical Engineering, Technion Analyzing Aborts in Software Transactional Memory Submitted by: Omer & Ofer Kiselov Supevised by: Dmitri Perelman
Transactional Memory and Aborts • Transactional Memory solution • An abstraction for critical sections in concurrent programming – transactions. • Easier and more intuitive for programmers than locks. • Implemented in both hardware and software. • The transaction abstraction • Each critical section is executed optimisticly. • Commit – Apply changes if correctness is maintained. • Abort – discard and rollback otherwise. • Aborts cause work waste and damages performance. • Some aborts are necessary • Commit may cause incorrect results. • And some are not, and could be avoided • Validating correctness is too complex to check through runtime.
Project Goals and Formation • Build a software analysis tool: • Abort statistics for a given run. • Unnecessary abort ratio. • Wasted work amount. • Will it pay of to add designs to stop the unnecessary aborts? • System is divided to two parts: • Online part to execute and log an STM program. • Offline part to read and analyze the log.
Online part • Modify Deuce STM to log the run • Insertion of logging commands to Deuce transactions code. • Transactions may call Logger class on reads, writes, commits and aborts • Logger writes log in XML format • Runs on 32-core system for high parallelism Deuce Framework Transactions Code: Start Read Write Commit Logger Log A Perfectly Scalable Code Collector iterates through the loggers, collecting data about actions by their order.
Offline Part • Read the log file and measure statistics: • Count aborts by their causes. • Maintain a precedence graph to check dependencies • Speculatively add aborted transactions’ edges to check abort necessity.
Conclusions • Parallelism increase → Abort rate and unnecessary abort rate increases. • Unnecessary abort rate relatively stable. • Paralleism increase → More aborts are caused by locked objects. • To improve performance over highly concurrent environements, more designs are required to reduce the unnecessary aborts.