RFR: 8311867: StructuredTaskScope.shutdown does not interrupt newly started threads

Jaikiran Pai jpai at openjdk.org
Wed Jul 12 11:51:17 UTC 2023


On Tue, 11 Jul 2023 17:03:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope.shutdown can sometimes not interrupt the thread for a newly forked subtask, leading to join blocking until subtask completes. The "hang" can be duplicated with a stress test that shuts down the scope while a long running subtask is being forked. The bug is in the underlying thread flock code where it filters the threads to just the live threads and so filters out new/unstarted threads, that filtering was left over from some refactoring in the loom repo a long time ago and should have been removed.

test/jdk/java/util/concurrent/StructuredTaskScope/StressShutdown.java line 83:

> 81:             // fork subtask to shutdown
> 82:             scope.fork(() -> {
> 83:                 scope.shutdown();

Hello Alan, the proposed source change in `ThreadFlock` and the reason for that change appear good to me.
However, as far as I understand, it appears to me that this test may not be reproducing the issue where shutdown gets called when there are threads that are about to start. From what I see in the API and implementation of `scope.fork()`, when the `fork()` returns, it's guaranteed that a `Thread` for the subtask has been started (keeping aside the failed to start cases). So in this test here, when we reach this point where we attempt a `shutdown()` all 15 "beforeShutdown" subtasks would already have threads that are started and alive. i.e. there won't be any "about to be started thread". As for the 15 "afterShutdown" forks() that follow, they would already notice that the scope is shutdown and won't start the new threads.
Did I misunderstand this test?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14833#discussion_r1261060214


More information about the core-libs-dev mailing list