Home > lambdatheultimate > Is Transactional Programming Actually Easier?

Is Transactional Programming Actually Easier?

September 7th, 2010 09:13 admin Leave a comment Go to comments

Is Transactional Programming Actually Easier?, WDDD ’09.

Chip multi-processors (CMPs) have become ubiquitous, while tools that ease concurrent programming have not. The promise of increased performance for all applications through ever more parallel hardware requires good tools for concurrent programming, especially for average programmers. Transactional memory (TM) has enjoyed recent interest as a tool that can help programmers program concurrently.

The TM research community claims that programming with transactional memory is easier than alternatives (like locks), but evidence is scant. In this paper, we describe a user-study in which 147 undergraduate students in an operating systems course implemented the same programs using coarse and fine-grain locks, monitors, and transactions. We surveyed the students after the assignment, and examined their code to determine the types and frequency of programming errors for each synchronization technique. Inexperienced programmers found baroque syntax a barrier to entry for transactional programming. On average, subjective evaluation showed that students found transactions harder to use than coarse-grain locks, but slightly easier to use than fine-grained locks. Detailed examination of synchronization errors in the students’ code tells a rather different story. Overwhelmingly, the number and types of programming errors the students made was much lower for transactions than for locks. On a similar programming problem, over 70% of students made errors with fine-grained locking, while less than 10% made errors with transactions.

I’ve recently discovered the Workshop on Duplicating, Deconstructing, and Debunking (WDDD) and have found a handful of neat papers, and this one seemed especially relevant to LtU.

Also, previously on LtU:

Transactional Memory versus Locks – A Comparative Case Study

Despite the fact Tommy McGuire’s post mentions Dr. Victor Pankratius’s talk was at UT-Austin and the authors of this WDDD’09 paper represent UT-Austin, these are two independent case studies with different programming assignments. The difference in assignments is interesting because it may indicate some statistical noise associated with problem domain complexity (as perceived by the test subjects) and could account for differences between the two studies.

Everyone always likes to talk about usability in programming languages without trying to do it. Some claim it can’t even be done, despite the fact Horning and Gannon did work on the subject 3+ decades ago, assessing how one can Language Design to Enhance Program Reliability. This gives a glimpse both on (a) why it is hard (b) how you can still try to do usability testing, rather than determine the truthiness of a language design decision.

Source: Is Transactional Programming Actually Easier?

Related Articles:

  1. Joe Duffy: A (brief) retrospective on transactional memory
  2. Has Flow-Based Programming’s Time Arrived?
  3. Students Looking For Easy A Target Online Courses, Where Cheating Is Easier
  4. Addressing Misconceptions About Code with Always-On Programming Visualizations
  5. Addressing Misconceptions About Code with Always-On Programming Visualizations
blog comments powered by Disqus