The previous race which I tried but in fact can not be fixed alone with
waitInflight flag is now described in the code comment in
PipeSleepStrategy::sleep().

To completely prevent the completer and the worker racing to the
new work notifications cqes we repurpose the cq_lock to ensure the
completer is always observing and honoring the waitInflight flag.

Also add an onNewWorkNotification callback to keep most sleep related
code and logic in PipeSleepStrategy.

[Make] use tidy make target instead of the meson generated clang-tidy target

See merge request i4/manycore/emper!247

[meson/liburing] switch to the official liburing wrap from meson wrapdb

See merge request i4/manycore/emper!246

[IoContext] die when the completer threads reaps new work notifications

See merge request i4/manycore/emper!245

The meson generated clang-tidy target uses compile_commands including
all code from subprojects and therefore fails due to code not in our control.
The gitlab CI also uses the tidy make target.

The PipeSleepStrategy uses the invariant that the completer thread
is not reaping IoContext of workers which have a read of the
sleep/notification pipe in flight.
This means that it can not reap CQEs resulting from such reads.
To esnure this invariant we DIE if the completer encounters completions
for such notifications.

[Debug] fix nanos in log timestamp

See merge request i4/manycore/emper!242

The timestamp consists of <hour><minutes>.<nanos> but the calculation of
the nanos in the current minute was broken.
A minute are 60 * 10^9 nanoseconds and not 10^9.

[liburing] bump the used wrap

See merge request i4/manycore/emper!241

Now EMPER builds using the liburing wrap succeed because they no longer
include liburing/src which contains a custom syscall header.

[Makefile] Make static-analysis depend on iwyu

See merge request i4/manycore/emper!240

[build] Emit a message if liburing subproject is used

See merge request i4/manycore/emper!239

The ninja 'iwyu' target does not depend nor generates
compile_commands_wo_subprojects/compile_commands.json. Hence iwyu
would fail if the database is not yet generated or run with an
outdated compile_commands.json.

Instead of iwyu being added to STATIC_ANALYSIS_NINJA_TARGETS, we now
have the static-analysis make target depend on iwyu. This ensures that
compile_commands_wo_subprojects/compile_commands.json is generated or
updated (if required) before iwyu is run.p

[IO] add shutdown(3) support

See merge request i4/manycore/emper!190

Consume liburing as meson wrap if native is not recent enough

See merge request i4/manycore/emper!238

[Future] Also log 'res' in LOGD of setCompletion(int32_t res)

See merge request i4/manycore/emper!237

[GlobalIoContext] Add CompleterSchedParam option

See merge request i4/manycore/emper!236

Generate a new compile_commands database in compile_commands_wo_subprojects/
without the files in subprojects/.
This new compile_commands database is than consumed by iwyu and clang-tidy.

Co-Authored-By: Florian Schmaus <schmaus@cs.fau.de>
Suggested--By: Florian Schmaus <schmaus@cs.fau.de>

It can't hurt to provide more information in log messages, especially
'res' is a good candidate in this case.

[IoContext] Add missing error handling in submitPreparedSqesAndWait()

See merge request i4/manycore/emper!235

[IoContext] Remove duplicate CQE_BATCH_COUNT delcaration and definition

See merge request i4/manycore/emper!233

This adds an option to make the scheduling parameters of the completer
thread configurable via a meson option.

Within the

do { reapAndScheduleCompletions() } while (io_uring_submit() == -EBUSY)

loop, the return value of io_uring_submit could be a negative value other
than EBUSY. In that case, we did not DIE.

Looking at the SubmitActor, where we have a very similar loop, the
error handling is correct. This changes the error handling in
IoContext to match the one of SubmitActor, even though it has a little
bit more overhead.

[IO] Implement configurable "simple architecture"

See merge request i4/manycore/emper!230

Introduce a new meson option io_single_uring which causes EMPER
to only use the GlobalIoContexts for all IO.

To submit SQEs to the io_uring SQ SubmitActor is used.

Futures can be in a new state where they are submitted to the SubmitActor
but not to the io_uring yet.
In this state isSubmitted && !isPrepared th Future must not be destroyed
to ensure this we yield when forgetting a Future until it is prepared
and thus it is safe to destroy it.

This commit contains no optimizations (no batching, no try non blocking
syscall first, ...)

Refacter GlobalIoContext.cpp:

* rename globalCompleter to completer
* make the completer loop non-static

Move all definitions from emper.hpp in compilation unit

See merge request i4/manycore/emper!232

Move emper::sleep() implemention from header in compilation unit

See merge request i4/manycore/emper!231

[AbstractWorkStealingScheduler] Get rid of "rand() % workerCount"

See merge request i4/manycore/emper!229

The "rand() % workerCount" constructed used in the work-stealing
scheduler is flawed. It has a bias toward lower worker IDs due the
modulo operation. This is something I always wanted to get rid of, but
never found the time to do it. Until know.

Get rid of it and replace it with
std::uniform_int_distribution<workerid_t> (as field the Worker
instance).

The main changes in AbstractWorkStealingScheduler are
- use currentWorker->nextRandomWorkerId() (instead of the flawed construct)
- currentWorker->getWorkerId() (instead of Runtime::getWorkerId())

[stats] blocked contexts

See merge request i4/manycore/emper!224