Clojure has a commute operator whose semantics seem appropriate to your concerns:
http://clojure.org/refs http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/commute Commute in haskell would be roughly :: TVar a -> (a -> a) -> STM a. The TVar touched by commute does not get marked such that the transaction could retry. Nor is the TVar itself even updated at the time. Rather, it is read, and the result of applying some transform to it is returned. Then, when the transaction commits, the tvar is atomically modified by the function and actually updated. This works if the operation commutes with all other operations performed on the TVar anywhere else that may be running concurrently, and if no essential use (i.e. requiring atomicity) is made of the value returned from commute. Both properties can only be enforced by the discipline of the programmer. I don't know how much discussion there's been in the Clojure community about the utility of commute, as a quick google mainly reveals people trying to either figure it out or explain it. Cheers, Sterl. On Sep 28, 2010, at 7:36 PM, Tom Hawkins wrote: > Thanks for the responses, but I think I should explain a bit more. > I'm not interested in being able to read the live value of a TVar at > any arbitrary time (via. unsafeIOToSTM). But rather I would like > looslyReadTVar to have exactly the same semantics as readTVar, except > that the STM runtime would not reject the transaction if the TVar is > modified by another transaction before the atomic commit takes place. > > Also, as I would be implementing something similar in Atom, I'm not > necessarily interested in a Haskell implementation, but rather if the > programming experience is elevated by these alternative semantics. > > For example: > > incr :: TVar -> STM () > incr a = looslyReadTVar a >>= writeTVar a . (+ 1) > > decr a :: TVar -> STM () > decr a = readTVar a >>= writeTVar a . (- 1) > > If incr and decr where atomically started at the same time with the > same TVar, decr would be rejected if incr completed first, but not the > other way around. The initial reaction may be that this seriously > breaks the atomicity of STM, but there may be cases where this could > be useful. For instance, it allow a computationally expensive > transactions to complete, even if their inputs are constantly being > modified. In the embedded domain, this could be a fault monitor that > reads a bunch of constantly changing sensors. > > -Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
