anchor.diff:  [[writing-tests-parallel-execution-synchronization]]
   ==== Synchronization
   
  -In the `org.junit.jupiter.api.parallel` package, JUnit Jupiter provides two
  -annotation-based declarative mechanisms to change the execution mode and allow for
  -synchronization when using shared resources in different tests.
  -
  -If parallel execution is enabled, all classes and methods are executed concurrently by
  -default. You can change the execution mode for the annotated element and its subelements
  -(if any) by using the `{Execution}` annotation. The following two modes are available:
  -
  -`SAME_THREAD`::
  -  Force execution in the same thread used by the parent. For example, when used on a test
  -  method, the test method will be executed in the same thread as any `@BeforeAll` or
  -  `@AfterAll` methods of the containing test class.
  -
  -`CONCURRENT`::
  -  Execute concurrently unless a resource lock forces execution in the same thread.
  -
  -In addition, the `{ResourceLock}` annotation allows you to declare that a test class or
  -method uses a specific shared resource that requires synchronized access to ensure
  -reliable test execution. The shared resource is identified by a unique name which is a
  -`String`. The name can be user-defined or one of the predefined constants in
  -`{Resources}`: `SYSTEM_PROPERTIES`, `SYSTEM_OUT`, or `SYSTEM_ERR`.
  +In addition to controlling the execution mode using the `{Execution}` annotation, JUnit
  +Jupiter provides another annotation-based declarative synchronization mechanism. The
  +`{ResourceLock}` annotation allows you to declare that a test class or method uses a
  +specific shared resource that requires synchronized access to ensure reliable test
  +execution. The shared resource is identified by a unique name which is a `String`. The
  +name can be user-defined or one of the predefined constants in `{Resources}`:
  +`SYSTEM_PROPERTIES`, `SYSTEM_OUT`, or `SYSTEM_ERR`.
   
   If the tests in the following example were run in parallel _without_ the use of
   {ResourceLock}, they would be _flaky_. Sometimes they would pass, and at other times they
  
positive.code: [[writing-tests-parallel-execution]]
  === Parallel Execution
  
  By default, JUnit Jupiter tests are run sequentially in a single thread. Running tests in
  parallel -- for example, to speed up execution -- is available as an opt-in feature since
  version 5.3. To enable parallel execution, set the
  
negative.code: example, in `junit-platform.properties` (see <<running-tests-config-params>> for other
  options).
  
  Enabling this property is but the first step to execute tests in parallel. If enabled,
  test classes and methods are still executed sequentially by default. Whether or not a node
  in the test tree is executed concurrently is controlled by its execution mode. The
  following two modes are available:
  
  `SAME_THREAD`::
    Force execution in the same thread used by the parent. For example, when used on a test
    method, the test method will be executed in the same thread as any `@BeforeAll` or
    `@AfterAll` methods of the containing test class.
  
  `CONCURRENT`::
    Execute concurrently unless a resource lock forces execution in the same thread.
  
  By default, nodes in the test tree use the `SAME_THREAD` execution mode. You can change
  the default by setting the `junit.jupiter.execution.parallel.mode.default` configuration
  parameter. Alternatively, you can use the `{Execution}` annotation to change the execution
  mode for the annotated element and its subelements (if any) which allows to activate
  parallel execution for individual test classes, one by one.
  
  [source,properties]
  .Configuration parameters to execute all tests in parallel
  ----
  junit.jupiter.execution.parallel.enabled = true
  junit.jupiter.execution.parallel.mode.default = concurrent
  ----
  
  The default execution mode is applied to all nodes of the test tree with a few notable
  exceptions, namely test classes that use the `Lifecycle.PER_CLASS` mode or a
  `{MethodOrderer}` (expect for `{Random}`). In the former case, test authors have to ensure
  that the test class is thread-safe; in the latter, concurrent execution might conflict
  with the configured execution order. Thus, in both cases, test methods in such test
  classes are only executed concurrently if the `@Execution(CONCURRENT)` annotation is
  present on the test class or method.
  
  All nodes of the test tree that with execution mode `CONCURRENT` will be executed fully in
  parallel according to the provided <<writing-tests-parallel-execution-config,
  configuration>> while observing the declarative
  <<writing-tests-parallel-execution-synchronization, synchronization>> mechanism. Please
  note that <<running-tests-capturing-output>> needs to be enabled separately.
  
  [[writing-tests-parallel-execution-config]]
  ==== Configuration
  