Re: C++ Threads, what's the status quo?
Mirek Fidler wrote:
Ahh... I guess you should seriously reconsider the issue.
Recommended reading is e.g. google: "why double checked guard does not
work".
Just for starters, if you have
Shared y;
Mutex y_lock;
void fn() {
y_lock.Lock();
y = 10;
y_lock.Unlock();
}
nothing in C++ standard prevents C++ compiler to generate machine code
equivalent to
void fn() {
y = 10;
y_lock.Lock();
y_lock.Unlock();
}
(and now I recommend you to get some C++ reeducation before your
threads start to fail with new compiler version ;)
First, I need to be really clear here. :) I did *NOT* write the code
above. You did. :D This could easily turn into a situation where people
start arguing that "my code does not work as expected." That is not my
code. And there is no place anywhere in any of my synchronization code
that uses double-checked locking. In fact, I did not even know what it
double-checked locking was (by name) until 15 minutes ago, after
finding a paper, per your suggestion. I did think about the concept
briefly, a few years ago, and soon realized that you get no free lunch
- that, if you want mutual exclusion, do not goof around. Ask for it,
have it, do your business, then let it go.
From this paper...
http://www.cs.wustl.edu/~schmidt/editorial-3.html
it should have been obvious that, barring the volatile keyword,
double-checked locking will not work, because the compiler could easily
out-wit the double-check lock programmer by not honouring the
"redundant" read of the "inexpensive" pseudo-semaphore (state
variable). I did not look further, but it is my suspicion that, even
with volatile, it could still be circumvented.
Again, I did *not* write the code above, nor does my code use
double-checked locking. And if it is also true that sequence points
are honored by the C++ Standard after a semi-colon, then my
multi-threading framework still works, with the optimizer enabled, and
is portable.
In fact, part of the reason I took the talk-to-the-kernel-mode-people
position early on in this thread is that I am afraid that there will be
many attempts to find "tricks" like this in hopes of accomplishing
inherently needs to be done by the OS and hardware, and perhaps due to
lack of experience, big parts of the C++ Community will be lead down a
fruitless path hoping for that which simply cannot be attained within
the context of the language alone.
I use real mutual exclusion, always, either as a
spin-lock-with-mutex-failorver or mutex-only. I do not engage in
non-portable tricks that might be broken by turning on the optimizer.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]