users_guide: Add note about #367 to Bugs section
ClosedPublic

Authored by bgamari on Aug 4 2015, 6:43 AM.

Details

Summary

This is a long-standing bug and should be mentioned in the users guide, as
noted in Trac #10639.

Test Plan

Carefully check language.

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
bgamari updated this revision to Diff 3753.Aug 4 2015, 6:43 AM
bgamari retitled this revision from to users_guide: Add note about #367 to Bugs section.
bgamari updated this object.
bgamari edited the test plan for this revision. (Show Details)
bgamari added a reviewer: simonpj.
bgamari updated the Trac tickets for this revision.
rwbarton requested changes to this revision.Aug 4 2015, 11:04 AM
rwbarton added a reviewer: rwbarton.
rwbarton added a subscriber: rwbarton.

Worth mentioning -fno-omit-yields right here without making people read through that ticket to learn about it.

This revision now requires changes to proceed.Aug 4 2015, 11:04 AM
bgamari updated this revision to Diff 3761.Aug 5 2015, 7:18 AM
bgamari edited edge metadata.
  • Note -fno-omit-yields
This revision was automatically updated to reflect the committed changes.

Sorry, I didn't notice this until now. I think there should be mention of STM specifically in addition to the general warning. STM without -fno-omit-yields can enter a non-allocating loop due to witnessing inconsistent data. This is a bit of a surprise to users as the point of using STM would be to avoid such inconsistencies.

Sorry, I didn't notice this until now. I think there should be mention of STM specifically in addition to the general warning. STM without -fno-omit-yields can enter a non-allocating loop due to witnessing inconsistent data. This is a bit of a surprise to users as the point of using STM would be to avoid such inconsistencies.

No worries.

Do you know of a Trac ticket where this was observed?

I don't know of any trac tickets about this specifically. I should try to make a small case and add a new ticket. In my research I encounter this problem with a red-black tree where one thread commits a tree rotation while another has read part way through a rotated node in a search. It observes inconsistent linking and loops through that cycle forever. I don't remember if I have ever observed it with stock GHC, but it is certainly possible. It becomes more likely with my hybrid-TM where hardware transactions can commit faster while a fallback software transaction path is searching the tree.