Asymmetric degrees of concurrency overlap

[jty2]

I have been measuring the amount of thread concurrency overlap and have found, at times, there is only ~50% of cycles where all specified threads are concurrently still trying to do enough lock_acquire() iterations. The typical behavior is that one thread will somehow finish much earlier than the others, and when it does, the rest of the threads see less contention and therefore achieve higher locking rate. However, only the average rate is reported by lockhammer, resulting in a misleadingly high-performance metric.

Instead of each thread attempting to lock for a specified number of iterations and returning the amount of time that has elapsed, each thread should continuously attempt locking for a fixed amount of time AND return the amount of time that has actually elapsed AND return the number of lock acquires. (For example, each thread is told to "attempt spamming locks for 1000000 timer clock ticks starting at global clock tick value 0x123deadbeef." and they return the start/stop timer ticks and the number of lock acquires.) This should ensure a higher percentage of all-thread concurrency during the measurement and with the added benefit of a bounded execution time.

[rpgolshan]

I think this is a great idea. Having the runtime go for a set amount of time instead of a set number of locks gives a clear idea about the amount of contention a test will produce. I do wonder what kind of performance effect we will see with this.

Does anyone else have input they would like to add about this idea?

[jty2]

Here is an implementation. Instead of -a num_acquires use -O num_clock_ticks. It should be possible to go even further and specify a wall-clock seconds duration.

jty2@d89628b