Software Transactional Memory?

[Erik Wikström]

On 2005-12-28 11:09, Ed wrote:
Someone used a "transactions system" that is found in modern databases to 
handle SMP. Quoting:

on modern machines, locks have become a major source of memory contention and 
often limit program performance. Transaction systems are able to avoid the 
lock-bottleneck by using higher-performance concurrency techniques such as 
fine-grain revocable locks and optimistic concurrency control, which would be 
impractically difficult for programmers to use directly. We have now reached 
the stage where transactions are outperforming locks --- and people are 
starting to get interested.

We have produced a new algorithm for implementing object based Software 
Transactional Memory that we have found to significantly outperform the 
previous best performing algorithms. When run on our 106-processor test 
machine, our algorithm is almost five times as fast as the previous best 
known algorithm under high contention, almost twice as fast when using large 
data sets, and we have yet to find any situation in which another STM 
outperforms it. 

We achieve this by taking care to minimise cache contention and 
memory-bandwidth requirements. This leads us to make very different --- often 
counter-intuitive --- choices to other STMs, and allows our algorithm to 
cause very little additional cache contention overhead, relative to a 
non-transactional program. 
The part about avoiding cache contention and not using locks sounds a 
bit like the work that has been going on in DFly (at least if I've 
understood things correctly), so it looks like Matt's ideas about how to 
 implement MP are valid. It will be interesting to see some perfomance 
tests when the whole kernel is out from BGL.

Erik Wikström
--
 "I have always wished for my computer to be as easy to use as my
 telephone; my wish has come true because I can no longer figure
 out how to use my telephone" -- Bjarne Stroustrup