3 ms·
I believe this is because the intermediate state can't be safely observed by another thread, since there's no locking, so the C++ memory model allows removing t
by foota 5y ago
I believe this is because the intermediate state can't be safely observed by another thread, since there's no locking, so the C++ memory model allows removing them.
- gpderetta 5y agoIn the article example itself, f1() and f2() can observe the state. Nothing to do with threads.
- Someone 5y agoI don’t think so. It is global state, but it lives outside the abstract C machine, in its implementation. The compiler knows f1 and f2 live in the abstract C machine and cannot access it. I think its like the difference between errno, a global inside the abstract C machine, and __foo, which a compiler might create, and, if it did so, could assume to be completely under its control.
- gpderetta 5y agoWell, sure we are deep into implementation details, so it is reasonable for the implementation to treat stores to it specially. But the rest of the article goes into details on how treating it specially causes "real pain in the neck" because the optimizer wants to optimize them away. It seems to me that if the store was not treated specially, the issue wouldn't exist in the first place. So either: exception handling in 32 bit mode is sort of an hack and the exception handling code generation doesn't actually expose the store the store through fs to the rest of the optimizer or, more likely, things are much much more complicated than described in the article.