Async / buffering wrapper: Improve performance when blocking on NetCore

[snakefoot]

ConcurrentRequestQueue - Improved DequeueBatch performance when blocking

Avoid activating throttle logic, when timer-thread is able to keep up. The throttle logic also affects the timer-thread, so only perform throttle-logic when timer-thread is falling behind.

And unit test for deadlock issue

[codecov-io]

Codecov Report

Merging #3416 into release/4.6.4 will decrease coverage by <1%.
The diff coverage is 89%.

@@              Coverage Diff               @@
##           release/4.6.4   #3416    +/-   ##
==============================================
- Coverage             80%     80%   -<1%     
==============================================
  Files                358     358            
  Lines              28373   28378     +5     
  Branches            3785    3784     -1     
==============================================
- Hits               22750   22740    -10     
- Misses              4537    4543     +6     
- Partials            1086    1095     +9

[304NotModified]

👍

[snakefoot]

Apparently hard to make a stable unit-test with multi-threading on the build-engines. One more try.

[snakefoot]

Hrmm. Don't like how the NetCoreApp2 unit test have become very unstable. Need to be checked.

[304NotModified]

Yes please check. Unstable tests are really slowing down development and releases. Maybe we should partly mock the unit test.

[304NotModified]

It's probably now more an integration test, like most "unit tests" in NLog.

[snakefoot]

Actually think it is a real bug, that has been revealed by the optimization of the dequeue-operation for the timer-thread. But right now the appveyor-build-queue has become very long, so it will have to look at it another day.

[304NotModified]

Maybe it's easier to run only on your appveyor account for this? Then you could stop/restart it yourself

See https://github.com/NLog/NLog/blob/dev/howto-build-your-fork.md

[snakefoot]

Think I have found the bug. After we have changed so blocking decrement/increments, then it means that timer-thread no longer automatically reschedules itself because it will not "see" producers by non-zero _count.

It is important now that the producers that wake up will remember to start the consumer-timer-thread, if needed.

Two producers that are blocked will get into TrySpinWaitForLowerCount() and it only performs Interlocked.Read. This means two producers will return with currentCount == 2. But one of them should have returned with currentCount = 1.

This causes both producers to say that they don't need to start the consumer-timer-thread

[304NotModified]

makes sense!

Thanks for figuring out and fixing this!