diff options
author | Ben Gamari <ben@smart-cactus.org> | 2019-12-01 15:08:33 -0500 |
---|---|---|
committer | Moritz Angermann <moritz.angermann@gmail.com> | 2020-09-18 07:37:02 +0000 |
commit | fa561839488be593791821b5e7b7c23b6ee7a1bd (patch) | |
tree | aae7beb44add43c9b797c99b49dfbd9b39365f55 | |
parent | f7a3a011ccc3b68f1cac98ed02f15e98dc7d8a93 (diff) | |
download | haskell-fa561839488be593791821b5e7b7c23b6ee7a1bd.tar.gz |
rts/Messages: Drop incredibly fishy write barrier
executeMessage previously had a write barrier at the beginning of its
loop apparently in an attempt to synchronize with another thread's
writes to the Message. I would guess that the author had intended to use
a load barrier here given that there are no globally-visible writes done
in executeMessage.
I've removed the redundant barrier since the necessary load barrier is
now provided by the ACQUIRE_LOAD.
-rw-r--r-- | rts/Messages.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/rts/Messages.c b/rts/Messages.c index c58f802077..89818b4b94 100644 --- a/rts/Messages.c +++ b/rts/Messages.c @@ -68,8 +68,6 @@ executeMessage (Capability *cap, Message *m) const StgInfoTable *i; loop: - write_barrier(); // allow m->header to be modified by another thread - // TODO: Is the above barrier actually needed? Why is it a write barrier? Something is fishy here. i = ACQUIRE_LOAD(&m->header.info); if (i == &stg_MSG_TRY_WAKEUP_info) { |