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

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

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

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

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

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.

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

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

makes sense!

Thanks for figuring out and fixing this!