In case a Context has been retrieved from the MemoryManager, without
it malloced, then we need to re-initialze some of the Context's values
before we can use the Context.

[SemaphoreWorkerSleepStrategy] Improve code comment

See merge request i4/manycore/emper!385

[gitlab-ci] Bump debian-testing-dev image to 1.23

See merge request i4/manycore/emper!391

Newer iwyu versions will exit with an error code in case include
issues have been found.

echoclient: initialize variable to fix building with gcc 12.1

See merge request i4/manycore/emper!388

pulse: only measure time between work creation and dispatching it

See merge request i4/manycore/emper!386

runtime: do not notify workers about termination if they do not sleep

See merge request i4/manycore/emper!387

I stumbled upon this because the no-sleep variants in the pulse evaluation
showed notifications in their stats.

We do not need to measure the work duration which is the known pulse.
This makes comparing the raw data easier because the latency does not
include the pulse duration.

fsearch: add possible semaphore limiting the concurrenct open requests

See merge request i4/manycore/emper!382

add additional mode of introducing work

See merge request i4/manycore/emper!383

The default is Burst mode which inserts new work as fast as possible
sleeping until the next pulse.
Even mode distributes the new work evenly in the duration between two
pulses.

Improve pulse evaluation

See merge request i4/manycore/emper!381

[io] Transform assert() to EMPER_ASSERT_MSG() in GlobalIoContext

See merge request i4/manycore/emper!380

[apps/FibChildStealing] Improve fibNum arg parsing

See merge request i4/manycore/emper!379

We recently saw this assert triggering in our CI. Let's yank up its
verbosity.

Also, don't set an unsigned to -1…

make sleep semaphore threshold configurable

See merge request i4/manycore/emper!378

increase the sleep semaphore threshold

See merge request i4/manycore/emper!377

Pulse: initial pulse evaluation commit

See merge request i4/manycore/emper!376

fsearch: add more fine grained control about the used fiber throttles

See merge request i4/manycore/emper!375

Also remove the negation of the condition (!> equals <=).

We currently use the semaphore of our sleep strategy very greedy.
This is due to skipping the semaphore's V() operation if we are sure
that it does not kill our progress guaranty.

When scheduling new work from within the runtime we skip the wakeup if
we observe nobody sleeping. This is fine in terms of progress and
limits the amount of atomic operations on global state to a minimum.

Using a threshold of 0 (observe nobody sleeping) however introduces a
race between inserting new work and going to sleep which harm the
latency when the worker goes to sleep and is not notified about the
new work.

This race is common and can be observed in the pulse micro benchmark.
A emper with a threshold of 0 shows high latency compared to using
an io-based sleep strategy or when increasing the threshold.

$ build-release/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1721970116.425

$ build-increased-sem-threshold/eval/pulse | python -c "<calc mean"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000023942.15

$ build-pipe-release/eval/pulse | python -c "<calc mean>
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000030557.0861111

$ build-pipe-no-completer/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000021514.1805556

I could not measure any significant overhead due to the more atomics
on my 16 core machine using the fs-eval on a SSD.

$ ./eval.py -r 50 -i emper-vanilla emper-inc-sem-threshold emper-pipe emper-pipe-no-completer
...
$ ./summarize.py results/1599f44-dirty-pasture/<date>/ -f '{target}-{median} (+- {std})'
duration_time:u:
emper-vanilla-0.202106189 (+- 0.016075981812486713)
emper-inc-sem-threshold-0.2049344115 (+- 0.015348506939891596)
emper-pipe-0.21689131 (+- 0.015198438371285145)
emper-pipe-no-completer-0.1372724185 (+- 0.005865720218833998)

add io synchronous option

See merge request i4/manycore/emper!373