From d71d19731f593d6d09d7cb982f0cde46d07787d1 Mon Sep 17 00:00:00 2001
From: Ian Lynagh <ian@well-typed.com>
Date: Thu, 3 Jan 2013 22:34:21 +0000
Subject: [PATCH] Revert "MERGED: Fix a bug in the handling of nested orElse"
This reverts commit 5ea49271f793ed0f872342bf6a1cb0de10a48d94.
---
rts/STM.c | 24 +++---------------------
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/rts/STM.c b/rts/STM.c
index b9883589925b..f8f56a29056c 100644
--- a/rts/STM.c
+++ b/rts/STM.c
@@ -1447,28 +1447,10 @@ StgBool stmCommitNestedTransaction(Capability *cap, StgTRecHeader *trec) {
StgTVar *s;
s = e -> tvar;
-
- // Careful! We might have a read entry here that we don't want
- // to spam over the update entry in the enclosing TRec. e.g. in
- //
- // t <- newTVar 1
- // writeTVar t 2
- // ((readTVar t >> retry) `orElse` return ()) `orElse` return ()
- //
- // - the innermost txn first aborts, giving us a read-only entry
- // with e->expected_value == e->new_value == 1
- // - the inner orElse commits into the outer orElse, which
- // lands us here. If we unconditionally did
- // merge_update_into(), then we would overwrite the outer
- // TRec's update, so we must check whether the entry is an
- // update or not, and if not, just do merge_read_into.
- //
- if (entry_is_update(e)) {
+ if (entry_is_update(e)) {
unlock_tvar(trec, s, e -> expected_value, FALSE);
- merge_update_into(cap, et, s, e -> expected_value, e -> new_value);
- } else {
- merge_read_into(cap, et, s, e -> expected_value);
- }
+ }
+ merge_update_into(cap, et, s, e -> expected_value, e -> new_value);
ACQ_ASSERT(s -> current_value != (StgClosure *)trec);
});
} else {
--
GitLab