Re: Threading in new C++ standard
On May 4, 1:54 am, "Boehm, Hans" <hans.bo...@hp.com> wrote:
On May 3, 2:41 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 2, 10:05 pm, "Boehm, Hans" <hans.bo...@hp.com> wrote:
[...]
But in practice, not everything is best expressed using mutual
exclusion.
Perhaps not at the low level such as at the library level. But at the
language level certainly everything is best expressed using mutual
exclusion. Note that mutual exclusion is a high level concept and the
compiler can decide whether it applies locks or not. It becomes an
optimisation issue. The reason is that in the situation you claim it
is not "best expressed using mutual exclusion", there still you mean
you ensured mutual exclusion by some other means for that specific
scenario. Well, if the compiler can detect it, it can relax the use of
the so much feared locks.
Lazy initialization, in various forms, for example is a
common exception.
It is not only a common exception but a detectable pattern too. So the
compiler can detect such uses of the shared variables (provided you
communicate your intention properly such as marking of shared
variables and Critical Regions) and the compiler can insert
appropriate low level synchronisation for that. The main issue is that
if you as the programmer do not over-specify what to do (see instruct
the machine) compilers will have the freedom to optimise your code.
Lock-based (or critical-regotto willing to pay that
when the alternative is much cheaper, and often nearly free.
Lock-based is allow level concept not appearing in any high level
language (see instructing the machine). The Critical Region, on the
other hand, is a language level notion. Whether the compiler
implements a Critical Region with locks or with any other _cheaper_
means, it is an implementation question (see the machines to execute
our programs).
"There are two views of programming. In the old view it is regarded as
the purpose of our programs to instruct our machines; in the new one
it will be the purpose of our machines to execute our
programs." (1975)
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html
[...]
Nevertheless, if you move from the one sequential automaton to the
many cooperating sequential automata, you better make your intention
clear and say that you really want to regard the two operations as a
unit. The conventional language means for this is the (Conditional)
Critical Region:
Thread 1:
with (x, x_init) {
x = 42;
x_init = true;
}
Thread 2:
with (x, x_init) when (x_init) {
assert(x == 42);
}
which hides the fact that x = 42 and assert(x == 42) do not need
mutual exclusion.
Oh yes, they do need mutual exclusion. Only in your original example
you are trying to impose that property by silent arrangement in the
program construction. You described it in words to me rather than you
did put it into the notation. Now, if you use Critical Region, you
have expressed your intention in the code both to another reader of
the code (and you do not have to explain) and to the compiler.
Consequently, the compiler can detect the situation and it can
implement the high level Critical Region exactly with the low level
notation you originally proposed. So, we are at the same code in the
implementation, only it is much more safe.
Do not forget:
<quote note="from earlier message" location=
"http://groups.google.com/group/comp.lang.c++/msg/27a4737cbcd8ddcc">
Once C++ was a success because it could add object-oriented
programming concepts to a procedural language. Stroustrup himself
claims that it did not seem such a straightforward idea to take up
object-oriented programming: "all sensible people "knew" that OOP
didn't work in the real world: It was too slow (by more than an order
of magnitude), far too difficult for programmers to use, didn't apply
to real-world problems, and couldn't interact with all the rest of the
code needed in a system."
http://ddj.com/cpp/207000124
The situation is very similar now with respect to concurrency at the
language level. All sensible people "knows" that it is inefficient to
have it at the language level. All sensible people "knows" that you
need memory model and visibility concerns. You need a brave step for
the success, though. Otherwise C++0x will be yet another library-based
language.
</quote>
In real cases those tend to be complex object
initializations and accesses, which may be 100 or 1000 times more
expensive than the x_init accesses. Without read-sharing,this
solution is completely impractical when you have multiple readers like
thread 2. If you use something like a rwlock, you are still left with
often a large slowdown slowdown in the reader versus the atomics -
based implementation.
Only you do not have to use low level rwlock at the language level
since you have the higher level Critical Region.
You basically have to compile it to one or two
rwlock acquisitions, vs. an ordinary load instruction on X86.
Basically, it is the decision in the optimisation part of the compiler
whether on a given architecture it applies rwlock or not.
Best Regards,
Szabolcs