-2

I want to implement Obstruction Free STM (OFTM) using Haskell to benchmark various available contention management policies. For example, a Transaction T1 acquires a Tvar, say X and yet to commit. Now another Transaction T2 wants to access X. In Haskell STM, T2 is being blocked and retries later. I want that Transaction will execute in non-blocking fashion where T2 will abort T1 or back off for some arbitrary time by consulting contention manager. And T1 will retry later on. As it happens in case of Aggressive contention manager, which always chooses to abort an enemy transaction at conflict time. It is just an experiment I want to do. Thanks in advance.

Ammlan Ghosh
  • 365
  • 3
  • 12
  • 2
    I think this question is rather too broad for StackOverflow - can you try to narrow it down? – Ganesh Sittampalam Jan 16 '15 at 10:00
  • @GaneshSittampalam How to implement non-blocking STM using Haskell, where second transaction does not require to wait. – Ammlan Ghosh Jan 16 '15 at 10:02
  • For example ask about specific problems you're having doing that, details of what you've tried/what's not working, etc. – Ganesh Sittampalam Jan 16 '15 at 10:16
  • 1
    As far as I know the stm package in hackage is already obstruction free. – Jeremy List Jan 16 '15 at 10:27
  • AFAIK, Haskell's STM implementation provides no fairness guarantees:a transaction is allow to starve indefinitely. Your question is about rewriting the implementation so that certain transactions have higher priority than the others, so that they can not only not starve, but they can not even retry, being run in a wait-free fashion. This looks as an interesting large project. Unless some library already provides something like that, I don't think a SO answer can include all of this STM redesign. – chi Jan 16 '15 at 10:30
  • @JeremyList, how to implement new contention management policy in Haskell STM? – Ammlan Ghosh Jan 19 '15 at 06:04

1 Answers1

2

First: The default STM implementation does not "block" conflicting transactions. Rather, every transaction runs at full speed, and conflicts are only detected at the commit stage. When a transaction tries to commit, it either succeeds, or it gets aborted and immediately restarts the transaction. It does not at any point "block". (You're perhaps thinking of the retry primitive, which does block transactions.)

Second: There was an issue of The Monad Reader (no, I don't recall which number) which described an implementation of STM where transaction conflicts immediately rollback one of the conflicting transactions (which one depends on timing). You may find it interesting. (On the other hand, the code isn't accessible, so...)

Edit: It was issue 15 (final section).

MathematicalOrchid
  • 61,854
  • 19
  • 123
  • 220
  • This might be better as a comment than an answer - the only content that might answer the question is in the link. – Ganesh Sittampalam Jan 16 '15 at 12:59
  • @MathematicalOrchid, thanks for your answer. I was trying to implement contention management policies [link] (https://www.cs.rochester.edu/u/scott/papers/2005_PODC_CM.pdf) in Haskell those were used in Dynamic Software Transactional Memory. Let me read the PDF you have linked; I hope it would be helpful for me. – Ammlan Ghosh Jan 19 '15 at 06:13