Do not resurrect all dead threads at once
Needs RevisionPublic

Authored by osa1 on Apr 30 2018, 5:15 AM.

Details

Reviewers
simonmar
bgamari
erikd
Trac Issues
#10241
Summary

Just a proof-of-concept.

Resurrecting a thread may make some other threads reachable. To avoid
resurrecting these other threads we continue with scavenging after resurrecting
one thread, instead of resurrecting all threads.

Because the scavenge loop loops more times this may have some performance
implications.

Test Plan

This validates.

osa1 created this revision.Apr 30 2018, 5:15 AM
osa1 updated this revision to Diff 16221.Apr 30 2018, 5:18 AM
This comment was removed by osa1.
osa1 updated this revision to Diff 16225.Apr 30 2018, 7:17 AM
This comment was removed by osa1.
osa1 updated this revision to Diff 16226.Apr 30 2018, 7:18 AM

whitespace

osa1 requested review of this revision.Apr 30 2018, 8:33 AM
osa1 edited the summary of this revision. (Show Details)
osa1 edited the test plan for this revision. (Show Details)
osa1 updated this revision to Diff 16230.Apr 30 2018, 8:45 AM
  • Add test

I'm not sure I follow the reasoning here.

simonmar requested changes to this revision.May 1 2018, 2:13 PM

The problem with this is that it's non-deterministic - it makes a difference which thread you resurrect first, and we have no way to tell which order to resurrect threads in.

This revision now requires changes to proceed.May 1 2018, 2:13 PM
osa1 added a comment.May 1 2018, 2:31 PM

I'm not sure I follow the reasoning here.

The reasoning is explained in the ticket, comment:1.

The problem with this is that it's non-deterministic - it makes a difference which thread you resurrect first, and we have no way to tell which order to resurrect threads in.

Right, I didn't think that's a problem because scheduling and garbage collection are already non-deterministic, which makes BlockedIndefinitelyOnMVar non-deterministic as well. If this is not OK (why?) then perhaps we should close Trac #10241 and Trac #10793 (and any tickets in the future) as WONTFIX. Or do you think this can be done in a deterministic way?

In D4644#128693, @osa1 wrote:

The problem with this is that it's non-deterministic - it makes a difference which thread you resurrect first, and we have no way to tell which order to resurrect threads in.

Right, I didn't think that's a problem because scheduling and garbage collection are already non-deterministic, which makes BlockedIndefinitelyOnMVar non-deterministic as well. If this is not OK (why?) then perhaps we should close Trac #10241 and Trac #10793 (and any tickets in the future) as WONTFIX. Or do you think this can be done in a deterministic way?

Yes, scheduling is non-deterministic (GC is not, though - the set of threads determined to be deadlocked will always be the same). It is possible to write a program that will non-deterministically deadlock. But the problem with the approach in this diff is that even if you write a program that deterministically deadlocks, it can behave non-deterministically with respect to BlockedIndefinitelyOnMVar exceptions, which is not currently the case. We should not introduce any new non-determinism, especially when it's not under the control of the programmer.

Yes I think we should close Trac #10241 as wontfix. As for Trac #10793, there's a suggestion in the comment thread for something else that we could do that would still be deterministic but would allow more useful behaviour in that case.