1 / 6

Analyzing Aborts in Software Transactional Memory

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

nodin
Download Presentation

Analyzing Aborts in Software Transactional Memory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Networked Software Systems Lab Department of Electrical Engineering, Technion Analyzing Aborts in Software Transactional Memory Submitted by: Omer & Ofer Kiselov Supevised by: Dmitri Perelman

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

More Related