ck_sequence test vs docs about ck HOT 3 CLOSED

Hi @joelnn

Would it be possible to get more detail on the problem statement? I'm aware of the paper, but I don't understand the problem you're trying to point out. Note, the paper is talking about intersection of programming language memory models and the raciness of read-side sections in seqlock.

I would ask you re-open the issue or file another with more details.

For more information, there are generally two classes of issues:

1. Optimizers (particularly on older compilers) have been observed to not play nicely with some expectations of algorithms. In particular, if non-volatile loads and stores are being used we have observed breakage or bugs with respect to dependencies on volatile (ck_pr) operations.
2. Compilers are free to generate non-temporal stores or loads which will break ordering assumptions required by some algorithms.

Are you encountering a problem with ck_seqlock?

from ck.

Hi @sbahra. I was hoping to use a seqlock in the form given in the man page, ie do some arbitrary reads inside the lock, without the further help of ck functions.

Finding that change to the test code made me doubt whether I would be on solid ground doing that with a modern/correct compiler. Granted it’s not totally clear which compilers are correct, but that’s what I look to CK for.

But the issue I meant to raise is just: the test code should not be less vulnerable to compiler issues than any documented usages. So if the test code change was needed to make the tests pass on a toolchain CK (still) cares about, the man page should probably reflect it too.

from ck.

I haven't found any issues with modern compilers and arbitrary reads are permitted. You do raise a good point, I'll update the test to include an ifdef for older compilers that are not doing the right thing here.

Edit -- (when I get a chance, it's unfortunately a low priority item on my list so no idea when I'll get to it).

from ck.