Feature/concurrency utils

[pvonwirth]

New Feature: Lock-Free Single-Input, Single-Output Buffer
Unittests provided

[pvonwirth]

@mbloechli
I assigned you as reviewer here, because the pre-commit check fails.
However, the problem that is shown that causes this failure is not existing in this feature branch.
However, this problem has been introduced within the fest/TUM branch.
I.e., somehow these checks are checking out the wrong branch for evaluation.
I guess that's something for you to fix, isn't it?

[mbloechli]

@mbloechli I assigned you as reviewer here, because the pre-commit check fails. However, the problem that is shown that causes this failure is not existing in this feature branch. However, this problem has been introduced within the fest/TUM branch. I.e., somehow these checks are checking out the wrong branch for evaluation. I guess that's something for you to fix, isn't it?

Are you sure it's checking out another branch? To me it looks just like the problem in linting has been introduced by an earlier PR to main, which was back then ignored. pre-commit is not just checking your edits, but all files of the repo in general. So if the your base from where you branched from was already failing pre-commit test before, your test will fail as well if you don't fix what caused the pre-commit error.

To check pre-commit for all files you can execute locally 'pre-commit run --all'. If that command fails locally, it will also fail in the tests here.

[pvonwirth]

If that command fails locally, it will also fail in the tests here.
Well, that's exactly the point: locally, it is not failing!

If you check out the file that lint is complaining about: the line that is bad (trailing whitespace) is not existing in my branch. Nor it is existing in main ...
But it had been introduced in the fest/TUM Branch (commit b6b6517 the second last in this branch right before merge 'main' into fest/TUM)

That's why it's so strange to me.

[mbloechli]

Is it not existing in main? The nightly test that run this night for pre-commit failed exactly the same way. I've now also run a pre-commit locally on main and it fails at that place.

I think I know what happens. Since your branch is behind main it doesn't yet include the bug that was introduced by fest/TUM and thus succeeds the pre-commit test locally. But the one in the github workflow runs pre-commit after executing the merge to main locally. I didn't know that either, but it does make sense that pre-commit workflow tests the state after a locally executed merge to main.

[pvonwirth]

@mbloechli
Ok, sorry. That makes total sense, now.
I checked against main, rather than origin/main ...
Just fixed the issue.
You wanna approve this PR ?

[mbloechli]

@pvonwirth I can only review from the formal side, not on your content itself. For this you better ask @firesurfer or @bbaier-duatic.

I see that you created a new package for this function. Since I don't understand the content, I can't judge if it makes sense to keep your concurrency utils in a seperate package instead of integrating it into the existing packages of duatic_helpers.

[mbloechli]

Please add a README.md to duatic_concurrency explaining this packages purpose and how people should use it.

[pvonwirth]

ok, I'll hand it over.

Readme updated, Code-review handed over