Stream: t-lang/wg-unsafe-code-guidelines

Topic: Volatile


RalfJ (Jun 26 2019 at 20:16, on Zulip):

https://github.com/rust-lang/unsafe-code-guidelines/issues/152 makes me so sad :(

RalfJ (Jun 26 2019 at 20:17, on Zulip):

The OP was all about the interaction with concurrency, and now everyone drowns that in a discussion about volatile load/store tearing that is only relevant for MMIO

gnzlbg (Jun 26 2019 at 20:55, on Zulip):

How is tearing only relevant for MMIO ? If you have two threads reading/writing from/to shared memory using volatile, those can tear

gnzlbg (Jun 26 2019 at 20:56, on Zulip):

so tearing quite intrinsic to volatile

RalfJ (Jun 26 2019 at 20:57, on Zulip):

that thread is about being able to do reads that returns arbitrary but initialized data in case of a race

gnzlbg (Jun 26 2019 at 20:57, on Zulip):

one of the main reasons data-races are UB in C is because of tearing

RalfJ (Jun 26 2019 at 20:57, on Zulip):

whether tearing happens or not is irrelevant

RalfJ (Jun 26 2019 at 20:57, on Zulip):

no

RalfJ (Jun 26 2019 at 20:57, on Zulip):

the main reason data races are UB in C is because C compilers like to duplicate reads

RalfJ (Jun 26 2019 at 20:57, on Zulip):

which is much worse than tearing

gnzlbg (Jun 26 2019 at 21:10, on Zulip):

i wouldn't say they are much worse - they are differently worse

RalfJ (Jun 26 2019 at 21:13, on Zulip):

no it's strictly worse. every effect you might have with tearing, you also have with duplicate reads, and more.

RalfJ (Jun 26 2019 at 21:21, on Zulip):

and in particular, when the guarantee in case of a data-race is "give me any data", then tearing just is not a problem

RalfJ (Jun 26 2019 at 21:21, on Zulip):

even doing byte-wise reads would be fine, as long as every byte is only read once

RalfJ (Jun 26 2019 at 21:21, on Zulip):

this is what makes the entire tearing discussion off-topic for the original question

Last update: Nov 19 2019 at 19:00UTC