Tramp

Ali-Reza Adl-Tabatabai, Richard L. Hudson,

Vijay Menon, Yang Ni, Bratin Saha,

Tatiana Shpeisman, Adam Welc

TM Semantic and Current Languages

Success of TM is dependent on acceptance by practitioners

+ Practitioners are resistant to changing their languages and SDEs

Therefore

Adding TM to current languages is important

Isolation is where tension between TM and other language semantics is most acute

Non-Repeatable Reads

Thread 1:

atomic {

t1 = x;

t2 = x;

}

Initially x == 0

Thread 2:

x = 1;

Can t1 != t2 ?

Intermediate Dirty Read

Thread 1:

atomic {

x++;

x++;

}

Initially x == 0

Thread 2:

t = x;

Can t be odd?

Limit the scope of TM

Should we distinguish between Transactional Memory and Transactional Execution?

Should we train students not to think of it as Java synchronization on steroids?

Should we be optimizing for 1 HW thread per SW thread?

– This changes the equations w.r.t. premption safety.

Rethinking TM HW Support

TM is a language construct that eases programming

• Integrated into a language environment– Debugger, Editor, Performance Monitoring

• Will be subject to aggressive SW optimizations – Compiler writers have really big brains

HW TM support must factor in a mature SW stack

Analogies: Object orientation, Garbage collection

• Lots of HW proposed based on un-optimized SW stack

• Fell by the wayside after SW evolved

Limit HW Support, Expand Applicability

Focus on acceleration of STM (and other) constructs

Leave semantics and policy to SW.

Largest obstacle may be single thread performance

Keep proposals simple or it won’t be built in time to help TM.

Demonstrate mechanisms are applicable to more that TM

Rethinking the stack

Sophisticated OS and virtual machine algorithms could be simplified

New SDE for concurrent programming.

Suppose you preserve read sets, write sets, serialization order of transactional blocks.

Could cost be similar to that of a leak detector or a race condition detector?

Such a system would allow data mining of execution as well as deterministic replay for performance or debugging.

As a practitioner this would be very useful to me.

Let’s do it in concert with the HW being rethought around many cores.

Thanks