[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video

Tim Harris (RESEARCH) tharris at microsoft.com
Tue Nov 28 06:28:42 EST 2006


> After seeing how close I could come to creating onRetry/retryWith I have a
> question about the semantics of your idea for retryWith.
> Normally after a retry the STM block is rolled back and put to sleep and
> will
> only be awakened and re-executed if one of the STM variables it had read
> from is
> committed to by a different STM block.
> What about retryWith ?  Will the STM block be put to sleep under the same
> conditions?  Can the IO action given to retryWith include commits to STM
> variables?

Starting with this last question -- yes, the example of an STM GetLine using retryWith to pull more input into a buffer relies on an atomic block in the IO action to update the buffer.

There are some interesting questions to think about the semantics of "retryWith".  The semantics of "retry" in the PPoPP paper say nothing about putting threads to sleep -- it would be correct for an implementation to spin repeatedly executing an "atomic" block until it completes without calling "retry".  What should happen with "retryWith" -- should we introduce blocking & wake-up into the semantics, or say that the "retryWith" actions are collected together, executed in place of the transaction (if it does ultimately retry) and then the transaction re-attempted?  For simplicity (and to leave flexibility to the implementation) I'd prefer to keep blocking & wake-up out of the semantics.

Taking that option, suppose we have "atomic { X }" and X retries with IO action Y.  I think I'm saying that that would be equivalent to "Y ; atomic { X }".  What are the consequences of this?  In the GetLine example it means that an implementation that does put threads to sleep must detect conflicts between the first execution of X and any transactions performed in Y.

Are there any interesting problems that come up if "Y" performs transactions that use "retry" or "retryWith"?


More information about the Haskell-Cafe mailing list