Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

threadpool: sync() deadlocks in high-CPU-usage scenarios #11250

Closed
stefantalpalaru opened this issue May 14, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@stefantalpalaru
Copy link
Contributor

commented May 14, 2019

There is a window in sync() between the time it's determined that some workers are busy and the time it waits for those workers to signal(gSomeReady). Within that interval, workers may be shut down based on advice() logic so they never get a chance to execute that signal(), hence the deadlock.

Replication

To replicate this, we need to put a maximum load on all cores. I'm using the Prime95 (the package is named "gimps" on Gentoo) torture test:

/opt/gimps/mprime -t

In another terminal, compile "tflowvar.nim" and run it in a loop:

PATH="./bin:$PATH" nim c -f --debugger:native tests/parallel/tflowvar.nim
I=0; while true; do echo $(( I = I +1 )); PATH="./bin:$PATH" tests/parallel/tflowvar; sleep 0.1; done

It will hang after a few iterations. At that point, you can attach gdb to it and verify that currentPoolSize has decreased (from 8 to 7 on my 8-cores FX-8320E) because of a worker shutting down during sync().

stefantalpalaru added a commit to stefantalpalaru/Nim that referenced this issue May 14, 2019

@Araq Araq closed this in dfc7685 May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.