Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
Pete Becker wrote:
Le Chaud Lapin wrote:
The mutex is simpler but slower:
Mutex counter_mutex; // global
void increment_counter ()
{
counter_mutex.acquire();
++count;
counter_mutex.release();
}
The increment has no visible side effects, so the compiler is not
obliged to sandwich it between the acquire and the release. How do you
ensure that the compiler won't do either of those?
I would take whatever recourse is available in all situations like
these. If I may answer with an example...
No, you may not answer with an example. Answer with code whose meaning
is well-defined under the C++ standard as it exists today. Otherwise
you're just engaging in meaningless handwaving.
[sample code illustrating similar problem omitted]
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?
--
-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]