Is Transactional Programming Actually Easier?

Is Transactional Programming Actually Easier?Christopher J. Rossbach, Owen S. Hofmann, Emmett WitchelUniversity of Texas at Austin, USATransactional Memory: Motivation MantraWe need better parallel programming tools(Concurrent programming == programming w/locks)Locks are difficultCMP ubiquity urgencyTransactional memory is promising:No deadlock, livelock, etc.Optimistic likely more scalable Conclusion:Transactional Memory is easier than locksCorollary: All TM papers should be publishedAverage programmer

2Is TM really easier than locks?Programmers still must write critical sectionsRealizable TM will have new issuesHTM overflowSTM performanceTrading one set of difficult issues for another?Ease-of-use is a critical motivator for TM research

Its important to know the answer to this question

How can we answer this question?Step 2: have them write the same program with TM and locksStep 4: Evaluate their codeStep 3: Ask them how it wentStep 1: Get some programmers(preferrably inexperienced)This talk: TM vs. locks user study UT Austin OS undergrads same program using locks (fine/coarse) monitors transactional memoryOutlineMotivationProgramming ProblemUser Study MethodologyResultsConclusionThe programming problemsync-gallery: a rogues gallery of synchronizationMetaphor shooting gallery (welcome to Texas)Rogues shoot paint-balls in lanes (1 red, 1 blue)Cleaners change targets back to white

Unshot laneShot by blue rogueShot by redrogueSync-gallery invariantsOnly one shooter per lane (Uh, hello, dangerous?!)Dont shoot colored lanes (no fun)Clean only when all lanes shot (be lazy)Only one cleaner at a time

Shot by both roguesSync-gallery ImplementationsProgram specification variationsSingle-laneTwo-laneCleaner (condition vars + additional thread)Synchronization primitive variationsCoarse: single global lockFine: per lane locksTransactional Memory

Variation 1: single-lane rogueRogue() {while(true) { Lane lane = randomLane(); if(lane.getColor() == WHITE) lane.shoot(); if(allLanesShot()) clean(); }}Invariants: One shooter per lane Dont shoot colored lanes One cleaner thread Clean only when all lanes shotglobalLock.lock()globalLock.unlock()lane.lock()lane.unlock()lockAllLanes() ???beginTransaction()endTransaction()Coarse-grain lockingFine-grain lockingTransactionsVariation 2: two-lane rogueRogue() {while(true) { Lane a = randomLane(); Lane b = randomLane(); if(a.getColor() == WHITE && b.getColor() == WHITE) { a.shoot(); b.shoot(); } if(allLanesShot()) clean(); }}Invariants: One shooter per lane Dont shoot colored lanes One cleaner thread Clean only when all lanes shotglobalLock.lock()globalLock.unlock()Coarse-grain lockingFine-grain lockinga.lock();b.lock();Requires lock-ordering!lockAllLanes() ???Dont say miraculous

10Variation 3: cleaner roguesRogue() {while(true) Lane lane = randomLane(); if(lane.getColor() == WHITE) lane.shoot();} }Cleaner() { while(true) { if(allLanesShot())clean(); } }Invariants: One shooter per lane Dont shoot colored lanes One cleaner thread Clean only when all lanes shotif(allLanesShot()) lanesFull.signal();while(!allLanesShot() lanesFull.await()(still need other locks!)Synchronization Cross-productCoarseFineTMSingle-laneCoarseFineTMTwo-laneCoarse2Fine2TM2CleanerCoarseCleanerFineCleanerTMCleaner9 different Rogue implementationsFind a way to emphasize what is interestingCIRCLE THE ITEMS Im talking about12OutlineMotivationProgramming ProblemUser Study MethodologyTM SupportSurvey detailsResultsConclusionTM SupportYear 1: DSTM2 [Herlihy 06]Year 2+3: JDASTM [Ramadan 09]Library, not language supportNo atomic blocksRead/write barriers encapsulated in lib callsDifferent concrete syntax matters

DSTM2 concrete syntaxCallable c = new Callable { public Void call() {GalleryLane l = randomLane(); if(l.color() == WHITE)) l.shoot(myColor);return null; }}Thread.doIt(c); // transaction hereJDASTM concrete syntaxTransaction tx = new Transaction(id);boolean done = false;while(!done) { try { tx.BeginTransaction(); GalleryLane l = randomLane(); if(l.TM_color() == WHITE)) l.TM_shoot(myColor); done = tx.CommitTransaction(); } catch(AbortException e) { tx.AbortTransaction(); done = false; }}Undergrads: the ideal TM user-baseTM added to undergrad OS curriculumSurvey accompanies sync-gallery projectAnalyze programming mistakesTMs benchmark for successEasier to use than fine grain locks or conditions

REWORK17SurveyMeasure previous exposureUsed locks/TM before, etcTrack design/code/debug timeRank primitives according along several axes:Ease of reasoning aboutEase of coding/debuggingEase of understanding others codehttp://www.cs.utexas.edu/~witchel/tx/sync-gallery-survey.html

Data collectionSurveyed 5 sections of OS students 2 sections x 2 semesters + 1 section x 1 semester237 students1323 rogue implementationsDefect AnalysisAutomated testing using condorExamined all implementations

OutlineMotivationProgramming ProblemUser Study MethodologyResultsConclusionDevelopment Effort: year 2hoursCIRCLE the data points21Development Effort: year 2hoursImplementation order:Coarserand&2?FineTMCIRCLE the data points22Development Effort: year 2hoursCIRCLE the data points23Development Effort: year 2hoursCIRCLE the data points24Qualitative preferences: year 2Ranking1234Coarse62%30%1%4%Fine6%21%45%40%TM26%32%19%21%Conditions6%21%29%40%Ranking1234Coarse81%14%1%3%Fine1%38%30%29%TM16%32%30%21%Conditions4%14%40%40%Best SyntaxEasiest to Think about(Year 2)Qualitative preferences: year 2Ranking1234Coarse62%30%1%4%Fine6%21%45%40%TM26%32%19%21%Conditions6%21%29%40%Ranking1234Coarse81%14%1%3%Fine1%38%30%29%TM16%32%30%21%Conditions4%14%40%40%Best SyntaxEasiest to Think about(Year 2)Easiest to Think aboutCoarseTMFineConditionsEasierHarderQualitative preferences: year 2Ranking1234Coarse62%30%1%4%Fine6%21%45%40%TM26%32%19%21%Conditions6%21%29%40%Ranking1234Coarse81%14%1%3%Fine1%38%30%29%TM16%32%30%21%Conditions4%14%40%40%Best SyntaxEasiest to Think about(Year 2)Best SyntaxCoarseTMFineConditionsEasierHarderTalk through this27Analyzing Programming ErrorsError taxonomy: 10 classesLock-ord: lock orderingLock-cond: checking condition outside critsecLock-forgot: forgotten SynchronizationLock-exotic: inscrutable lock usageCv-exotic: exotic condition variable usageCv-use: condition variable errorsTM-exotic: TM primitive misuseTM-forgot: Forgotten TM synchronizationTM-cond: Checking conditions outside critsecTM-order: Ordering in TM

Error Rates by Defect Typecv-use: 63%TM: 0-27%Note that its mostly 0 for TM.Different years are color-coded29Overall Error RatesProportion of errorsGeometric Mean: Coarse Locks: 27% Fine Locks: 62% TM: 10%Locks: 58-75%TM: 8-20%OutlineMotivationProgramming ProblemUser Study MethodologyResultsConclusionConclusionGeneral qualitative ranking:Coarse-grain locks (easiest)TMFine-grain locks/conditions (hardest)Error rates overwhelmingly in favor of TMTM may actually be easierOverall Error Rates: Year 2Proportion of errors