The current implementation of ZSTM suffers from "retry storms." For example, short transactions can force long-running ones to retry.

To verify this behavior, I've set the following benchmark:

• make a TRef containing a list of 10000 elements
• have multiple short transactions updating only the head of the list
• have one transaction increment all elements
• race them

Running this benchmark on the current implementation produces the following result:

Benchmark                             Mode  Cnt  Score     Error  Units
STMRetryBenchmark.mixedTransactions  thrpt   15  0.125   ± 0.219  ops/s

The solution to this problem is to count the number of retries, and obtain a global lock once this count breaches some predefined limit. Acquiring a global lock should allow a long-running transaction to complete. To avoid paying the high locking "price," the number of max retries should be chosen from [10, 100]. Based on the results of my trial benchmarks, I've decided to set it to 10.

With this change in place, the benchmark mentioned above produced the following result:

Benchmark                             Mode  Cnt  Score     Error  Units
STMRetryBenchmark.mixedTransactions  thrpt   15  425.153   ± 4.321  ops/s