Re: C++ Threads, what's the status quo?
peter koch larsen wrote:
{ Redundant signature removed. -mod/aps }
Le Chaud Lapin skrev:
James Kanze wrote:
Except if one of the writes migrates across a spin-lock.
(Spin-locks are only guaranteed if special hardware instructions
are used on a Sparc---or a PC. Hardware instructions that are
never generated by Sun CC or by g++---or by the current version
of VC++.)
Uh, yes they are. People who write device drivers using them all the
time. In fact, they are used so often, Microsoft make special library
functions just for spin-locks. Microsoft uses spin-locks in its own
implementation of what they call critical sections.
Right. But this is not code generated by the compiler but rather
(assembly) code used by the compi?er-
Just to be clear, there is an entire family of Interlocked-XXXX
functions available on Windows that are available for use.
First you have to define what that part is. Suppose that the
library writer says that you need to manually acquire a lock
before calling malloc (or operator new)?
I would ask the library writer why he did that when it does not make
sense. It is better to have a thread-safe new() which I use in all my
multi-threaded code.
Okay! But this is one of the areas where the C++ standard is going to
change. It will say something in the direction of that new must be
reentrant.
The heap requires global state, so if new() and delete() are made
generally reentrant, there will be an unavoidable associated cost.
What does does a single-threaded programmer do when he is told that
new() is reentrant and he simply has to live with this fact?
Another thing it will say is that the compiler is not
allowed to reorder code across certain function calls (e.g. calls to
mutexes), and that it must allow two threads to simultaneously throw an
exception.
This might be a good idea in general. Seems that, even in the world of
single-threaded applications, this would be a problem, if some feel
that it is a problem.
I believe that most of the work on the standard will use their effort
on this subject and the C++ memory model in order to assure that
"newer" lock-free techniques can be used from C++.
:) Now we get to the real issue. I think that a big fight is
forthcoming, not now, but in the future. I inferred from reading
between the lines of post that there were some people who had lock-free
techniques in mind but were not explicitly saying so. I also inferred
that some people do not particularly like lock-free techniques. I am
indifferent. But one thing is certain, whatever approach is taken, C++
will not be the C++ of today. The change will be semi-radical. It
will start to influence how programmers think about system structure.
Saying that a C++ class is not thread safe because objects of the class
all operate on a global variable...that's obvious.
This is not obvious at all. On the contrary, many would expect that two
threads would be able to simultaneously read data and also call some
constant functions such as e.g. std::vector<>.begin(),
std::vector<>.end() and std::vector<>operator[]. The standard does not
give us such promises yet, and we will have to revert to the compiler
documentation in order to verify the behavior of our program.
This is, again, a difference of expectations. The first thing I see
when I see a global object that has a member function being invoked on
it, const or not, is that the function might result in a perturbation
of state. I ask myself, if this is going to be a problem in a
multi-threaded application. If the answer is yes, I add protection.
If the answer is no, I use no protection. If the answer is "I don't
know", I add protection.
There are others who might interpret the semantics of const to apply to
multi-threading also. Note here, however, that const will not mitigate
the effects of a mutable member variable. So it was never the case
that const means, "will not change."
But again, this is a difference of expectation.
Now if you are saying that the C++ committee needs to structure there
libraries so that that they can be single-threaded and multi-threaded,
I agree with that, but that is the library, not the language proper.
And I have always said that this is a library issue more than anything.
Those libraries are part of the standard, and it is not just a library
issue. The "difficult" part is IMHO the memory model and the new
thread-related libraries (if they are to appear).
Yes, someone is going to have to take a consensus of expectations on
say, map<>. It will be have to be determined, what is the "mood" or
"mentality" of a programmer when s/he uses a global const map<>. This
will get very interesting indeed.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]