IRC channel logs

<ZhaoM>It's so nice the channel log works again :)

<azert>sneek: later tell ZhaoM that I don’t think you need atomic fetches if the variable that is fetched is volatile. There shouldn’t be any race if that’s the case

<sneek>Okay.

<azert>Since an access to a volatile variable is considered a side effect, it is done for real and not optimized

<azert>If I’m mistaken and the variable isn’t volatile, then you can cast it to volatile

<youpi>that's however only when you are reading just one word. if you are reading several words they may be incoherent.

<azert>youpi: in this case it would be a multi word number, right? Then you need to make sure you read the most significant words first and you are good

<azert>ordering matters

<youpi>azert: even reading the most significant first will lead to incoherent data

<youpi>if in-between you have a carry between the low-significant part and the high-significant part

<youpi>e.g from 0,99 to 1,00, you might read 0,00

<azert>Sure

<azert>how come I didn’t think of that

<azert>what is an efficient way of doing it correctly?

<azert>overlapping words? error detection bits?

<youpi>what is already there

<youpi>a check bit

<youpi>see check_seconds in struct mapped_time_value

<ZhaoM>hello

<sneek>ZhaoM, you have 1 message!

<sneek>ZhaoM, azert says: that I don’t think you need atomic fetches if the variable that is fetched is volatile. There shouldn’t be any race if that’s the case

IRC channel logs

2024-12-18.log