AsyncWrapper: Improve performance when blocking

[snakefoot]

ConcurrentRequestQueue - Always see queue as empty after reached RequestLimit (and resolved it)

When reaching the RequestLimit, then producers perform asymmetric update of queue-count.

Instead of trying to coordinate which of the producers should signal start-timer, then all producers will signal start-timer since it is "exceptional" situation.

[codecov-io]

Codecov Report

Merging #3435 into release/4.6.4 will increase coverage by <1%.
The diff coverage is 75%.

@@              Coverage Diff               @@
##           release/4.6.4   #3435    +/-   ##
==============================================
+ Coverage             80%     80%   +<1%     
==============================================
  Files                358     358            
  Lines              28514   28514            
  Branches            3813    3813            
==============================================
+ Hits               22825   22844    +19     
+ Misses              4589    4574    -15     
+ Partials            1100    1096     -4

[304NotModified]

Hi,

Is this a bug fix or an (performance)enhancement?

[snakefoot]

It is continuation from #3416 where I tried to fix the "bug" of failing to handle a RequestLimit of 2 with Blocking-mode.

It is a simplification of the previous commit. So instead of trying to be clever then it just takes a performance hit when blocking mode has been activated.

The simplication reduces the number of modifications of the _count variable, so less memory write barriers are needed when blocking mode is activated. Improves the concurrency of the producers as they are less chatty.

But now all producers will eagerly try to wake the timer-thread after blocking mode has been activated. This might kill any performance gain from improving producer concurrency.

But I like the simplicity of this change, and my simple performance tests still shows good performance

[304NotModified]

thanks! Merged!