

Ask YC: A simpler STM implementation? - andr

I'm pondering an STM (http://en.wikipedia.org/wiki/Software_transactional_memory) implementation in C#. For me, the main reason to use STM is not because I think locking is complicated, but because of the speed gains. With that said, I find the current STM implementations (in .NET, at least) cumbersome and slow, because they involve cloning and a proxy object for every single object.<p>So I have thought of several potential improvements to traditional STM, which bring it closer to optimistic locking, and wanted to hear your opinion:<p>1) Lock on race conditions.<p>Go ahead and execute the transaction, but if you detect a conflict, acquire a lock on the relevant object and execute the transaction again. Seems like a better decision, with a guaranteed worst execution time, than implementing some kind of throttling.<p>2) Non-transactional objects.<p>The idea is to have an STM method like so:<p><pre><code>    void STMExecute&#60;T&#62;(T obj, Func&#60;T, bool&#62; transaction, Func&#60;T, bool&#62; failsafeTransaction)
</code></pre>
(FYI in C#, Func&#60;T1, ..., Tn, TR&#62; is a lambda with parameters of types T1..n and return type TR.)<p>STMExecute would keep track of the generation counter for obj, run the transaction lambda, and if it fails, or there is a conflict, acquire a lock on obj, and run failsafeTransaction.<p>For example, in a banking system, transaction would increment the account (obj)'s balance by 100, and failsafeTransaction would recompute the balance by going through the history of withdrawals and deposits for the account.<p>3) No side effect functions<p>STMExecute would be changed to<p><pre><code>    void STMExecute&#60;T&#62;(ref T obj, Func&#60;T, T&#62; transaction)
</code></pre>
transaction would return a new T instance based on the original object, without changing the original object. True, there is some cloning involved, but it works without proxy objects.<p>A potential issue is that C# doesn't offer a way to enforce transactions have no side effects. This can be done by making immutable types, though.<p>4) What is a good benchmark?<p>What's a good, realistic way to test the performance of STM, compared to locks? The most obvious way - run several threads like so:<p><pre><code>    while (true) {
        STMExecute(ref var, x =&#62; x + 1);
    }
</code></pre>
would always show locks as the winner, as STMExecute will default to locks when a conflict occurs. This scenario is unrealistic, though. Any better ideas?
======
cx01
"For me, the main reason to use STM is not because I think locking is
complicated, but because of the speed gains."

I'm rather confident that STM is a lot slower than locking. Wasn't the main
idea of STM to simplify coding while sacrificing some performance?

~~~
andr
I know, but I'm trying to get the best parts of STM to actually get an
improvement in performance.

~~~
cx01
I don't think that's possible, but would be happy if proven wrong. I just
downloaded the STM implementation and it seems to include some benchmarks. So
that could be at least an answer to your question 4.

