Failing faster might even improve performance a little bit to offset the loss of performance because of checking more often.

The WHOLE point of STM is enabling nesting of atomic transactions. It is only in this respect that STM is superior to other concurrency control structures.

What STM does is solve the composability problem. Specifically, during a transaction I can use outside code (such as libraries) which, in turn, require transactions, without being vulnerable to lock order issues (which lead to live locks and dead locks). But that’s only true, of course, if you can nest STM transactions.

If that’s not true, then you don’t have STM, you have something that looks like STM. See Composable Operations in the link you got your syntax from.

It’s hard to say. I didn’t do any serious testing, but it’s a simple enough library that you shouldn’t have many problems. The source is all BSD licensed (except for Vector, which is CPL), so you’re more than free to take it and do what you will.

Cheers
Patrick

I really like the monadic approach to STM as it is implemented in GHC Haskell. It’s unfortunate that Scala’s for-comprehensions are so much more verbose than Haskell’s. It was partially for this reason that I ruled out monads fairly early in my design process.

The implicits actually came out of an attempt to make the explicit API (your first design) a little less verbose. After some more thought, it occurred to me that I could use scoping rules to favor one transaction type over another, and the rest just fell into place.

@Asd

> 1. Oracle transactions do not work like that.

I never said they did, I was only attempting to point out that databases have been using transactions for a very long time.

> 2. Read outside a transaction is a big hole that’ll let people make mistakes

Weak transactional semantics are a certainly a point of contention. It is a whole which allows potentially inconsistent state between reads, but it is assumed that users of the API will be aware of this and the tradeoffs. If you need integrity in the reads, move them into a transaction and return an atomic aggregate result.

It would be possible to provide two different types of refs, one with strong and the other with weak semantics. There’s nothing really in the design of this STM library which would forbid such an approach, I just didn’t take it.

> 3. It is not necessarily easier to get transaction right than it is to get locks right. Every update might be in a transaction, but it might be the wrong transaction

I’m not sure what you mean by “the wrong transaction”. As a general rule, if you put some operation in a transaction, it is *guaranteed* to both maintain and operate on fully-consistent data. It doesn’t actually matter which transaction the operations are distributed across. It is true that you may be able to derive a pathological distribution of tasks which leads to trouble due to concurrent ordering of mutually dependent operations, but that would certainly be a contrived case. Even in such a scenario, the data itself would remain consistent with respect to the operations, the final results would simply be indeterminate.

> 4. Nested atomic ops = uh-oh

Some STM systems actually allow nested atomic ops without any problems at all. You are correct in pointing out that with the STM designed here, we would run into problems. However, I’m sure that with a little thought, it would be possible to statically restrict the `atomic` method to only operate outside of a transaction.

2. Read outside a transaction is a big hole that’ll let people make mistakes

3. It is not necessarily easier to get transaction right than it is to get locks right. Every update might be in a transaction, but it might be the wrong transaction

4. Nested atomic ops = uh-oh