Re: C++ Threads, what's the status quo?
{ 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-
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. 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.
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++.
What does "meant to be used in a multi-threaded application"
mean? For, say, tmpnam, or localtime? Or operator new, or
std::allocator?
When a person sits down to write a library, and it is after the year,
say, 1985, he should be thinking about whether that library will
operate in a single-threaded environment, a multi-threaded environment,
or both. And especially someone who writes a function that read/writes
static global state. There is nothing inherently wrong with that, but
the library writer should not go around peddling it as being
thread-safe. Obviously it is not.
And since you mention new(), what do you think all of us Windows people
do when we need to call new() in a multi-threaded application? Invoke
and hope that race condition does not manifest? No, we go to the IDE
options and change the drop-down menu from "Single Threaded Library" to
"Multi-Threaded Library". Recompile. All are happy.
> If the library implementation doesn't fulfil the contract, then
it is the library implementors fault. But for that to be the
case, you first need the contract.
Agreed. But the issues are a lot more complicated than you seem
to think. I know, from experience.
The problems you put forth seem to indicate otherwise. No offense, but
the cache synchronization issue, which I was well-aware of and
purposely avoided broaching so as not to let this thread degenerate
into a discussion on computer hardware, is one of the few legitimate
realms of uncertainty.
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.
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).
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]