Skip to content
This repository has been archived by the owner on Oct 12, 2022. It is now read-only.

fix Issue 15268 - deadlock for Thread.getAll/Thread.opApply #1421

Merged
merged 3 commits into from Oct 31, 2015

Conversation

MartinNowak
Copy link
Member

  • fix a deadlock caused by lock order inversion
  • must not use the GC while holding slock

- both Thread.remove and thread_suspendAll synchronize on slock
  so a double removal isn't possible
- we still set isRunning to false b/c some functions must not be called
  on a stopped thread, e.g. setPriority
- happens when removing a running thread (thread_detachInstance) that
  gets removed again at the end of thread_entryPoint
- fixed by setting .prev/.next to null on removal and checking for that
- requires the obvious care when removing threads while looping over the list
- also helps the GC a bit to collect dead Thread objects
- fix a deadlock caused by lock order inversion
- must not use the GC while holding slock
@dnadlinger
Copy link
Member

Auto-merge toggled on

dnadlinger added a commit that referenced this pull request Oct 31, 2015
fix Issue 15268 - deadlock for Thread.getAll/Thread.opApply
@dnadlinger dnadlinger merged commit 713aa05 into dlang:master Oct 31, 2015
@dnadlinger
Copy link
Member

Well, here goes nothing. I've tried my best to verify the changes, but it's pretty easy to mess up that piece of code.

@MartinNowak MartinNowak deleted the fix15268 branch October 31, 2015 09:47
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants