Jul 18, 2020

The problem is that, in this case, the code executed under the critical section cannot be easily visually verified to exit without reentry.

All other critical sections in libbitcoin are easily verified.

I see, complicated

Yep

Requires a good concurrency debugger. I’ve had it up in VS, which shows everything. Takes time to track tho. Reducing thread count helps a little.

I think we need to isolate which section of code the lock happens in and whether it's repeatable/deterministic across runs. It should be possible to see which sequence of invoke()s causes the lock.

C++23 will have boost::asio as executors

I can see all the threads idle, including the deadlock, in the debugger. That’s not the problem.

The full call stack for each thread is visible.

It is of course deterministic, it’s a computer :)

The deadlock is in the code I linked above.

It is of course repeatable, but it’s also a race condition.

I’ve debugged this same sort of issue before several times. V3 has been running for a couple years no with no occurrence of deadlock, and it is basically the same code. The new work in v4 is incomplete, which includes debugging this deadlock.

What can I do to help? I want to get a Python API working once there's a v4 lock.

Prolly not too much unfortunately. The outstanding work on v4 is not large in amount, but requires a lot of context. It takes me about a week to get my head back into it.

Understood