OpenMP critical section wait time in Fortran under high thread contention

The OpenMP specification guarantees mutual exclusion for any CRITICAL region but imposes no portable guarantee on acquisition order, wait time, or fairness under high thread contention.

Confirmed fact: A thread entering a CRITICAL region cannot be executed concurrently with another thread in the same region.

Likely explanation: The standard leaves the lock implementation to the runtime, so different compilers and runtimes may use FIFO, priority‑based, or adaptive spin‑lock algorithms, which can cause non‑deterministic worst‑case delays and possible thread starvation under sustained contention. This behavior is implementation‑defined and not portable.

If the critical region protects only a small data update, the developer must decide whether the overhead of the default lock is acceptable or whether to restructure the code to avoid serialization altogether.

1. Compile the Fortran source with the OpenMP flag of the chosen compiler (e.g., -fopenmp for GCC/Clang or /openmp for Intel).
2. Instrument the critical section with omp_get_wtime() before and after the region to record elapsed time.
3. Execute the program with varying thread counts (1, 2, 4, 8, 16) on the same hardware and workload, collecting the maximum observed latency.
4. Compare the measured latency for the default CRITICAL, for !$OMP ATOMIC (if the update is a single statement), and for alternatives such as REDUCTION or thread‑private accumulation.
5. If the latency grows super‑linearly or thread starvation is observed, consider redesigning the algorithm to shrink the critical section or eliminate it entirely.

Please provide the specific compiler version and runtime library (e.g., GCC 13 with libomp 13.0) used, as lock implementation can differ and affect the recommendation.