STM slightly conservative on write-only transactions

[JulesBean]

The STM appears to be slightly too conservative on write-only transactions.

It will store a copy of the current (that is, old) value on a writeTVar, even if it was never read from. This can cause a spurious retry.

E.g. atomically $ writeTVar tv 0 really has no reason to ever retry. Neither, in fact, does atomically $ mapM (\tv -> writeTVar tv 0) [tv1,tv2,tv3,tv4].

My suggestion is to instead indicate "no prior value" for that TVar, and then make no consistency checks on TVars marked as no prior value...

Jules

[simonpj]

Comment from Tim Harris:

This suggestion is OK from the point of view of correctness.

There are several special cases where we could allow transactions to commit when we currently treat them as conflicting. E.g. any single-word transaction is OK.

I've avoided dealing with too many of these in the absence of code we care about performing badly (it'll add complexity and might slow down the hopefully-common case of non-conflicting transactions).

No strong arguments against adding this one though: we could probably use a special value in the old-val field to indicate no-previous-value so we won't get a space code. We could also handle it specially in "retry" -- we don't need to watch for updates to a TVar that has been written to but not read.

[Isaac Dupree]

Probably I don't completely understand STM, but... if these happen at the same time, won't we potentially end up with an inconsistent state if no-one retries?

atomically $ mapM (\tv -> writeTVar tv 0) [tv1,tv2,tv3,tv4]

atomically $ mapM (\tv -> writeTVar tv 1) [tv4,tv3,tv2,tv1]

(and don't single-word transactions depend on the hardware/architecture as for whether they are atomic?)

[JulesBean]

No.

One them has to commit first. When it commits, it sets all the entries to something (say, 1). At this point, the other one has made no visible changes (all its changes are private, in its transaction log). Then, the other one commits, and it sets them all to 0.

Committing is atomic.

In the current situation what would happen is the first would commit, and then the second would say "erk! something has changed!" and not commit.