Re: Threads - When?
James Kanze wrote:
Le Chaud Lapin wrote:
So you don't work under Windows, Linux (at least on a PC) or
Solaris.
Don't know where you got that. My code works on all three for the most
part. What I said was that some OS's are just getting their
kernel-mode work into a state of closure, and Microsoft Windows is one
OS where it is more closed than not.
Or more likely, you're counting on some additional
guarantees from the implementation. Some of those guarantees
are pretty wide spread. Others not. The problem is that even
the widespread ones aren't part of the C++ standard (which
doesn't recognize threads) nor Posix (which doesn't recognize
C++). And not all are well documented, or even really
guaranteed from one release of the compiler to the next.
I do not think C++ should be thread-aware any more than it should be
"device driver" aware. I lose not one second of sleep knowing that, if
I have a multi-threaded application where two threads attack the same
global variable, there is potential for a race-condition. This is
obvious, and IMO, has nothing to do with C++.
I'm less concerned about the interface -- I can always wrap
that. I'm more concerned about the actual synchronization
issues. My own experience is that code written for g++ doesn't
work correctly with Sun CC, and vice versa, because the actual
guarantees given by each compiler are different.
The kernel-mode people should be concerned with synchronization issues,
not the compiler writer, IMO.
The first problem is the domain of the OS people.
Partially, although not completely. Typically, the OS people
define a C interface, and you have to depend on an
implementation specific mapping to C++. Thus:
std::string s ; // Initialized from argv...
void f()
{
static std::string t( "xxx" ) ; // OK with g++, not with Sun
CC
if ( s[ 0 ] == t[ 0 ] ) { // OK with Sun CC, not with
g++
}
}
What is not OK?
(I think that the g++ developpers consider this latter case an
error, and plan to fix it. There are other issues, like the
handling of pthread_cancel, however, where it is less than
obvious.)
Actually, test and set or an atomic xor are far from sufficient.
(They're also not typically available without actually writing
inline assembler.)
And that is a good thing, and is entirely congruent, for example, with
not having access to the instruction that forces a task switch, or an
instruction that flushes the translation look-aside buffer (TLB).
You can't do the first part until you define exactly what you
mean by synchronization. That's about the point where C++ is
now. And it's difficult, because you do want something that is
implementable (with reasonable overhead) on mainline systems.
I mean synchronization in Andy Tanenbaum's book on Operating System's
sense, and I do not think it is difficult. I am always surprised that
C++ think "there is a lack of support for threads.." in C++. There is
a lack of support for threads in any language. The support comes from
a few hardware primitives that guarantee atomicity and kernel-mode
software techniques that have been well-understood for almost 40 years.
I do not understand what magic C++ programmers expect the language to
perform. All paths will ultimately lead to whether you have a hardware
test-and-set or something like it, and the basics of kernel-mode
synchronization.
Now if people are dismayed that we do not have a *library* that
interfaces to hardware/kernel-mode primitives, then that is
understandable, but it should be recognized that, if you expect such a
library, you had better expect a piece of hardware or an OS that has
such primitives. If you do not have atomicity of fundamental
operations, there is *nothing* you can do. This is intuitively
obvious, and I would imagine that someone somewhere made it his thesis
to prove it.
I presume here that you are confusing the name of the system
request with the actual functionality it provides. I know of no
system today which provides a pure critical section; what
Windows calls a critical section is in fact a mutex.
There is no confusion. I wrote my first kernel-mode threading system
almost 20 years ago, that let you define C functions to be called back
from kernel in user-mode. This critical section is most likely
implemented as a spin-lock with failover to a mutex. There is really
no other way to do it. In fact, after finishing this post, I am going
to write a program to use one, break into the debugger, and check.
My timing measurements on Solaris suggest that
pthread_mutex_wait only calls the system when it has to,
regardless of the threading model being used. Since I don't
think Sun have some miracle technology unavailable to others, I
rather suspect that most systems do this.
Right, so if they are calling this a mutex, that's their choice. But
if it were a system-wide mutex, where multiple threads in different
processes needed to wait on the mutex, then there would be no user-mode
test-and-set (spin-locking), as the address spaces would be separate.
In that case, it would go to directly to the kernel, first time, every
time. This is simply a matter of choice of terminology. I did not
study the primitives on Solaris, but my gut feeling is that Microsoft
did some serious thinking in this area and got all their socks-on-feet
and gloves-on-hands. I would hope that Sun did the same thing. I
could not imagine that they did not.
Does sun have inter-process (named or unnamed) mutexes?
So to summarize: The OS people can make the primitives as raw and
unsightly as they want as long as the primitives are present and
complete. From that, it becomes easy to write a clean, C++ wrapper
framework to support robust multi-threading.
The problem is that there is no portable set of guarantees you
can count on.
Yes, that is hardly surprising, and no C++ compiler writer is going to
change that. They can influence that by having constructive
conversations with the people who will - the CPU manufacturers and
kernel-mode OS writers. Beyond the assumption that they have access to
atomic operations on a particular CPU, there is nothing that a C++
compiler writer is going to achieve to help C++ "support threads",
beyond implementing some kind of spin-lock.
Perhaps I am wrong, but I get the feeling that some people (not
necessarily you James) are not yet convinced that there is nothing you
can do inside the language proper to get synchronization to "work".
There is not! You might as well be having a conversation about how to
implement a portable cryptographically secure pseudo-random number
generator (CSPRNG) without asking the hardware and kernel-mode people
if every system upon with the CSPRNG is to be implemented will have a
source of entropy. If *hardware* or "kernel-mode" support is not
available, all bets are off.
Finally, I think it is delusional to think "We'll just tweak a little
bit here and there for the sake of global variables..." meaning that,
knowing that most hardware will probably provide some form of atomic
test-and-set/swap, etc., you try to create a systems where programmers
could expect global variables to be "covered".
You get two options: to wait or not to wait. There is no intermediate
state. You cannot block on access to a variable and simultaneously
pretend you are not waiting. You either spin, or you enter a
wait-state. There is nothing in between.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]