[GHC] #11713: STM Finalizers
GHC
ghc-devs at haskell.org
Wed Mar 16 16:12:01 UTC 2016
#11713: STM Finalizers
-------------------------------------+-------------------------------------
Reporter: mc.schroeder | Owner: mc.schroeder
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D2011
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by mc.schroeder):
Actually, instead of simply locking all TVars involved in a finalizing
transaction, my implementation "freezes" them, meaning they can still be
read by other transactions (preserving read-parallelism). Only when
another transaction tries to commit a write to a frozen TVar is its thread
blocked. It is woken up again when the finalizer that froze the TVar has
finished.
Of course, this could take a while (potentially forever), and all
transactions waiting on frozen TVars are stalled in the meantime.
However, I would say that this is exactly the point of finalizers: they
create a serialization point.
As for the potential of deadlocks due to nested transactions:
a deadlock could only occur if the inner transaction writes a TVar used by
the outer transaction. In my opinion, this is a rather artifical scenario,
that is unlikely to happen by accident. It will also always be detected by
the runtime system, which would then gracefully abort the transaction with
a BlockedIndefinitelyOnSTM exception.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11713#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list