Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

Daniel Tralamazza

Idea for lock extension for Java
I have a "simple" idea for lock composition. Everyone knows that locks are not scalable because they don't compose, not without breaking encapsulation at least.
Modern JVM's can merge locks of the same object if they are used inside the same function block (see http://www.ibm.com/developerworks/java/library/j-jtp10185/).
The idea is to use let the programmer specify explicitly which locks are composable, something like:
composable synchronized void add(int _v) {}
Both compiler and runtime would treat these synchronized methods & blocks differently. There are at least two possible scenarios: (#1) When composable locks are enclosed by a common parent lock, and (#2) no parent lock but just sibling locks.
synchronized (foo) {
  The VM would force a thread to always acquire the parent lock of a composable lock (recursive).
  All sibling composable locks should be acquired in the same order.
This is just a pre-draft of the idea, any comment is welcomed.
Posted by Daniel Tralamazza at 14:34
Concurrency Paradigms: A Comparison in Scala

Mohsen Lesani presented today a talk on his concurrency project using scala. He gave a great introduction on the different  concurrency control mechanisms:

  • Locks
  • STM
  • Actors
  • Wait-free algorithms

To compare them he implemented two different problems: Bank account transfer and Producer & Consumer. The former shows a clear isolation problem while the later poses a signaling issue. With these simple problems we can already see that there is no silver bullet in concurrent programming, i.e. no single technique can easily implement both problems and yield good performance at the same time.

For me it was interesting to discover that STMs lack signaling capabilities, after the presentation I talked to Mohsen and proposed that the signaling could maybe be done at the end of an atomic block (although I don't know how a thread could wait inside an atomic region).

You can see the presentation below.

Posted by Daniel Tralamazza at 15:31
XtraDB scalability

 Recently I discovered a new storage engine for MySQL called XtraDB. Since Oracle's acquisition of InnoDB MySQL is trying to find a substitute, but so far nothing has come close to its maturity and stability.

XtraDB is basically a InnoDB fork focused on scalability. What's so special about that ? Well their preliminary patches and benchmarks are exactly centered around locks. Most patches actually come from google-mysql-tools.

During a benchmark session on a 24-core machine the XtraDB team discovered a concurrency problem on the rollback segment.

Posted by Daniel Tralamazza at 13:54
Early Experience with a Commercial Hardware Transactional Memory Implementation

Finally (for me at least) Sun published a paper with performance measurements of their shiny new CPU Rock.

For those currently living under a rock (pun intended), this is the newest and delayed sparc processor from Sun which implements Hardware Transactional Memory (HTM).

The paper is available at Sun's Labs Scalable Synchronization Research Group soon to be published at ASPLOS'09.

Posted by Daniel Tralamazza at 14:27