Re: C++ Threads, what's the status quo?
Pete Becker wrote:
Le Chaud Lapin wrote:
[sample code by Chaud Lapin reaffirming what Pete wrote]
Technically, IIUC, the compiler has the right to reorder these two
statements, since they are visibly independent, thus launching the
missile at a potentially friendly neighboring country and subsequently
pointing the launch pad at the enemy.
Yup. And embedded programmers have to be very careful about what the
compiler does in order to make that sort of code work right. In
particular, you'd test that the code actually executed in the required
order. Do you propose doing that for every lock and unlock in a
multi-threaded program?
Well, I guess there are two options.
One, the whole issue of optimization (statement reordering in
particular) needs to be addressed (no pun intended), which is, in way,
separate from multi-threading, but definitely affects it. Not sure if
the people who like optimization will scream if someone says, "You need
to turn the optimizer off" if you want your code to execute correctly.
The other issue would be to add extra keywords to the language which
would be particular to threading that would prevent the compiler from
statement reordering. But then, I guess you would want to make those
keywords not thread-specific but useful in general.
For me, a lot of people are not going to like this, but if the compiler
did that with my code, I would turn off optimization for affected code,
which means not using macros for synchronization, etc. Not the best
solution.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]