Seqlock implementation extract

[nolan-veed]

Why

For #599

What

• Created a SeqlockImpl class and used it in SeqLock.

Testing

There are tests.

[github-actions]

🤖 Upon creation, pull request description does not have a link to an issue. If there is a related issue, please add it to the description using any of the supported formats.

[nolan-veed]

For some reason, my tests are hanging here...

[nolan-veed]

For some reason, my tests are hanging here...

Oh wait... the Timer is using Seqlock, so it's clearly uncovered a bug in my change.

[gavv]

Thanks!

[gavv]

If we will store pointer and size in members, then every call (try_store, try_load, etc) will involve two additional reads from memory, and the whole operation will depend on these reads.

If, instead, we will pass &val and sizeof(val) to these methods as arguments, then chances are that no memory reads are needed: &val can be calculated as this + offset, and this is likely already in register, and sizeof(val) is a constant. And then on many architectures like x86_64 ARM function arguments will be passed via registers.

In our code base Seqlock is often used for small frequently used variables, like counters. E.g. seqlock is a replacement for 64-bit atomics (because 64-bit atomics are not available everywhere). So it makes sense to keep seqlock overhead low and comparable with a regular atomic.

[gavv]

I guess we can move this method into .cpp file in anon namespace.

[gavv]

nit: extra empty line.

[nolan-veed]

Oh... we don't want to include the header related to the cpp file first?

[gavv]

Oh, it was intentional. Yes, current "defacto" code style uses:

<one block with stdlib headers>

<one block with external libs headers>

<one block with roc headers>

e.g.:

#include <stdio.h>
#include <stdlib.h>

#include <uv.h>

#include "roc_core/array.h"
#include "roc_core/time.h"

[gavv]

Thanks!

Small refactoring: 3ebb8c8 (see commit message for details)