Tests should use threads, not tasks about nonblocking

[VSadov]

Task.Factory.StartNew(body, TaskCreationOptions.LongRunning) starts a new thread because of LongRunning option.

Here we create threads:

            for (int i = 0; i < workers.Length; i++)
            {
                workers[i] = Task.Factory.StartNew(body, TaskCreationOptions.LongRunning);
            }

            stop_time = sw.ElapsedMilliseconds + time;

And here execution starts in all workers (which are all waiting for this event):

            e.Set();

The latency of an event is orders of magnitude faster than duration of one benchmark (3sec.), so
when a benchmark needs a particular degree of concurrency the above guarantees it quite reliably.

I do not think we have a problem here.

======= relevant code here:

NonBlocking/BenchmarksCore/Program.cs

Line 391 in 6c9824f

private static long RunBenchmark(Action<int, int> action, int threads, int time)

[VSadov]

For the tests - by default they run continuously and could be left running for hours.

While thread pool does not guarantee a particular concurrency mode, it appears to expose tests to all kind of random combinations (sequential or concurrent) and in practice catches problems really well.

[nerai]

Regarding LongRunning, I don't think the behavior of creating a new, separate thread is guaranteed:

LongRunning: Specifies that a task will be a long-running, coarse-grained operation involving fewer, larger components than fine-grained systems. It provides a hint to the TaskScheduler that oversubscription may be warranted. Oversubscription lets you create more threads than the available number of hardware threads. It also provides a hint to the task scheduler that an additional thread might be required for the task so that it does not block the forward progress of other threads or work items on the local thread-pool queue. [src]

[VSadov]

Tasks appear to work as expected. I do not think we have a problem here.