Fix TSAN bug by swapping ForkJoinPool with ScheduledExecutorService

[sjvanrossum]

This fixes the same issue as #39458 by having the ScheduledExecutorService establish a happens-before relationship between the submitting thread and executing thread, which appears to be missing for the common ForkJoinPool executor used by MoreFutures.runAsync(ThrowingRunnable) based on testing TFRecordSchemaTransformProviderTest with TSAN enabled. TSAN reports data races between the processing thread's write(s) to the Writer and the background thread's closing and/or cleanup of the Writer in CRC32 calls made by a gzip compressor.

Writer can be patched to establish acquire/release barriers between open and close/cleanup (e.g., by marking channel as volatile and adjusting reads/writes accordingly), but since write is abstract and the underlying WritableByteChannel is passed to implementations in prepareWrite instead of being accessed through its member field on the super class there's no point between any call to write and close which would insert the required memory barriers.

I can't think of any other tricks to make Writer inherently thread safe without modifying its public API as is already proposed in #39458. It is thread compatible at least, so it just needs external synchronization to play nice. Replacing the common ForkJoinPool with the harness ScheduledExecutorService as the executor for closing writers should be enough to take care of that.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[sjvanrossum]

I just came across JDK-8319447 and JDK-8386468, checking if that might have anything to do with TSAN's observations.
If so, then this is likely a false positive.

I'm thinking of writing a jcstress test case to reproduce the TSAN observations and validate whether that's truly observable behavior.
The setup would consist of an actor issuing a plain write to a field preceding a task submission to the common ForkJoinPool, reading the shared field from a pooled thread and having another actor join that task to observe the result for comparison.

I've got a full schedule today, but I'll see if I can put that together during my commute at the end of the day.

[github-actions]

Assigning reviewers:

R: @Abacn for label java.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[sjvanrossum]

@stankiewicz this looks like a false positive.
This test passes, but TSAN observes a stale read.

package forkjoinpooltsantest;

import static com.google.common.truth.Truth.assertWithMessage;

import java.util.concurrent.ForkJoinPool;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.JUnit4;

@RunWith(JUnit4.class)
public class ForkJoinPoolMemoryTest {

  private static final int STRESS_ITERATIONS = 100_000;
  private static final Object EXPECTED = new Object();

  /** Helper object containing plain (non-volatile) fields. */
  private static final class Holder {
    Object o;
  }

  @Test
  public void testCommonPoolSubmit_plainWriteIsAlwaysVisible() {
    for (int i = 0; i < STRESS_ITERATIONS; ++i) {
      final Holder holder = new Holder();
      holder.o = EXPECTED;

      // Submit a task to the common pool to read the value of the plain field, then join and
      // observe the returned value.
      Object observed = ForkJoinPool.commonPool().submit(() -> holder.o).join();

      assertWithMessage("Iteration %s: reference mismatch (possible stale read)", i)
          .that(observed)
          .isEqualTo(EXPECTED);
    }
  }
}