Multithreading is becoming an integral part of current and future application development. It is more important for super computer programmers, as each new generation of single node has more hardware threads than the previous generation. The two challenges of a parallel application is correctness and performance.

The primary difficulty in getting functionally correct parallel application from a sequential code is due to the race for shared data. Atomic instructions, locks and critical sections are the tools, used by parallel programmers to protect shared data. Locks and critical sections essentially convert a parallel portion of the code region to sequential execution.

An application using Coarse-grained locks will not yield to maximum performance. Transactional memory and Speculative execution borrow ideas from transactions in database to execute a shared code region in parallel. In speculative mode, the threads buffer all the writes to memory until the commit point. At commit point, the validity of the buffered data are evaluated by checking if a thread has conflicted with another threads. A conflict causes only one thread to commit the buffered data to memory, and the rest to rollback and retry.

BGQ is the first commercial hardware to have support for speculative execution. The compiler transforms the user annotated code region to parallel code and runtime library hooks. Upon hitting a speculative code region during the execution of the application, the runtime library configures the hardware threads to speculative mode, and passes the details of handling a conflict to the operating system.

The presentation will include details on how the hand shake between compiler, runtime, hardware and OS works. The insight into the details will allow the participants to decide on when to use Speculative Execution instead of conventional locks.