Re: std::string bad design????
James Kanze wrote:
Le Chaud Lapin wrote:
int x; // not thread-safe
I'm not sure I understand. This means that you don't do
preemptive multi-threading. (Which is the only kind you have
under Windows or Unix.)
?????? This does not make sense.
Note that _any_ data structure is "thread-unsafe". That is to be
expected. If you have a global variable, and N threads operate against
it, and that variable is not protected, there will be contention.
I'm not talking about global variables here. Without some
thread-safety guarantee, you cannot declare local instances of a
variable in different threads.
Not just "a variable". What you probably mean is that you cannot
declare local instances of a class that has member functions that
modify global state. All synchronization issues will ultimately lead
to some global variable being accessed by multiple-threads.
I have 100+ completely general purpose classes, including containers,
that are 100% "thread safe". I can declare as many "local instances"
as I want, and there will not be any contention...unless... I decide to
change the classes so that, upon every invocation of a member function,
they fiddle with a global variable, reading, writing, saying "Hello!"
Then, all of my classes would be "thread unsafe". Woe would be
everywhere.
This is a library issue, not a problem of the language proper.
Not with any of the implementations of the STL that I know. The
VC++ implementation is thread safe, as is the g++ one, and the
Remember, in general, under VC, you have to choose whether you want
thread-safe or "thread-unsafe" version of the library. Naturally, in
my applications, I link with the thread-safe versions.
Rogue Wave one provided with Sun CC. All of the original STL
has been thread safe since I've been using it, and long before.
(G++ had problems with string because it wasn't part of the
original STL, and they did a quick, albeit remarkably clean
implementation of it themselves. And they didn't make it
thread safe, since the code generated by the compiler wasn't
usable in a multithreaded environment to begin with.)
I do not understand this. Code becomes thread-safe by the application
of synchronization primitives. I am pretty sure I could take any of
those "thread-unsafe" compilers, compile my code, link with a
multi-threaded library, and have no issues.
I have my own equivalent of map<>. In fact, I have
several of them, and none of them use global variables.
So where do they get their memory from? All of the
implementations of malloc/operator new that I know use variables
with static lifetime.
operator new(). This new() is a global function. Therefore, if my
map<> does not do anything else funny, like access global variables,
then it is "thread safe".
Whether it was
necessary to use a global variable in the implementation of map<> is
another discussion, but this is about common sense. I do not think
anyone who has been writing multi-threaded applications, knowing what a
global variable is, will have any expectations otherwise.
If you use map<>, then you have to know what it guarantees.
Right, and map<> is part of a library, which is why I keep saying that
it is a library issue.
You might want to check
http://www.sgi.com/tech/stl/thread_safety.html; I'm pretty sure
that this corresponds to the thinking of the committee with
regards to how thread safety will be defined in the library.
(Except some special cases, like maybe std::cerr, and almost
certainly std::exit().)
I will take a look, but there is no need.
Right. You know it all, and everyone else is an idiot.
I know one thing: I do not have to worry about multi-threading on
Windows or Linux.
That page happens to be originally written by Hans Boehm and
Matt Austern. Two of the best experts I know.
Link was broken when I tried. Going to try again.
I can write a class Foo,
right now, make it so that it uses a global variable, run multiple
threads against it, and watch my program crash.
Right. Now can you get it through your head that the compiler
can also do this, and that the standard library can also do
this.
No it does not. The library writer does this. The compiler only
translates what it sees.
And that in fact, compilers and implementations of the
standard library have done it. And that you need guarantees
from the language and from the library specification concernig
what the guarantee to do, and what they guarantee not to do, and
that without those guarantees, you cannot write thread safe
code.
I disagree. I am confident that I know how to write thread-safe code
using existing compilers.
I definitely agree that engineering should be deliberate and
predictable. I cannot imagine that the people who designed the
standard library did not have multi-threading in the back of their
minds while making the library.
Imagine differently, then. STL was originally developped using
the old Borland C++ compiler, under MS-DOS. I'm 100% sure that
the author didn't take threading issues into account then.
Hmm..I remember MS-DOS. I wrote my first multi-tasker to bootstrap
from MS-DOS, Interrupt 19h on the timer. So now you are saying that
the people who designed "thread-unsafe" libraries should be forgiven
because it was long ago that they wrote it. Ok, I can do that. I just
do not think anyone should be surprised when inherently thread-unsafe
code manifests its lack of safety.
Even today, you often find disagreement concerning what
"thread-safe" means in a library, although a concensus is
gradually growing to adopt the Posix definition.
Thread-safe library or thread-safe code? I agree that some people seem
to have been writing thread-unsafe libraries.
Microsoft's approach, at least in part, has been to document
what you have to do to write thread safe code using their
development system. Using the correct version of the library is
part of it; I'm willing to bet that you also need specific
options to the compiler, or maybe a /D to define some
preprocessor symbol.
The essential part of multi-threading is to link to the library using
the /MT option. The rest is common sense.
http://msdn2.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
The problem there is that what you have to do will not be the
same as what you have to do with Sun CC, or with g++, under
Solaris. As I've stated repeatedly, Sun CC and g++ implement
different sets of rules, under Solaris.
What rules?
Another way of asking this is, "Is it possible to write multi-threaded
applications without changing the compilers on any of these machines?"
I've had to deal with this. I've had to modify code that was
carefully designed to work under the Sun CC rules, because it
didn't work with g++. It's a very real problem.
I do not doubt this. Based on what you are saying, I am quite sure
that, if I were to use map<> in my multi-threaded programs on Solaris,
it might crash. I would blame the implementation of map.
Having the standard address threading will solve this.
Obviously, you still need to use the primitives. The difference
is that it will be the same primitives you will need on all
systems, and using them will give you the same guarantees.
(Note that the fact that a global instance never changes does
not mean that you can access it without a lock with g++, even
today. This is in conflict with the usual Posix rules, however,
and at least some of the g++ development team consider it an
error.)
I would be *highly* interested in seeing an example of this. Node real
code necessary. Just give some sample code.
That's not been my experience (that it works very well today).
Of course, I have to support two systems (Solaris on Sparc and
Linux on PC), with a number of different versions of three
different compilers: Sun CC under Solaris, g++ under Solaris and
g++ under Linux. (Some of the lower level stuff also has to
work with VC++ 6.0 under Windows, but I'm not responsible for
that.)
So what _do_ you do when you write multi-threaded systems? I am looking
forward to seeing if my multi-threaded code crashes on Solaris someday.
Note that both Solaris and Linux are aim for Posix
compatibility, at least where threads are involved. But Posix
doesn't define a binding for C++, and the authors of Sun CC and
of g++ "exterpolated" the C binding differently for C++.
That's probably the best solution for an implementation, today.
You still have to define what is and what is not guaranteed in
the thread safe library, and I would very definitly like to see
this standardized
That is what I have been saying all along. It is a library issue, not
a "language proper" issue.
Note too that it goes beyond the library. G++ pre 3.0 used
static data in its implementation of stack walkback in
exceptions.
This falls in the "library" category, as far as I am concerned. There
is problem some function that does the walking.
You need a special option to the compiler driver under Solaris
or Linux as well; this special option takes care of defining the
correct #defines, using the correct libraries, etc. But the
guarantees you get still aren't standard, and code which worked
perfectly well with Sun CC failed with g++ (and vice versa).
Is the problem with the language proper or the library?
It doesn't affect recursion, since the compiler can arrange to
only do it when there are no function calls. But I agree, the
stack is the natural place to put them, at least on machines
with stacks and with decent based addressing modes. (It was
frequent for 8080 compilers to spill to static memory, but that
was because the 8080 had really bad support for based
addressing; to access a variable on the stack took something
like seven or eight instructions, and could only access bytes,
as opposed to a single instruction for 16 bit static values.)
Yes, and I can find you some PIC based-systems that have 12-bit words,
2KB of RAM, and boot sequence that consists of little more than
changing state of a few wires.
Still, there is a very large difference between my personal
feeling that the only reasonable way for a compiler to do
something is x, and a guarantee in the standard that something
must work.
I did not say the only reasonable. I said that, IMO, if there is
anyone who feels that changes to the grammar of C++ is necessary to
make "thread safe" code, they should try for the library approach
first, as it might reveal to them that it not only obviates changes to
the grammar, but the pattern of usage would parallel almost exactly
what they would be doing with new keywords.
If F calls G, G calls H, and H calls F, then spilling to static memory
in F would result in a dead end. The stack has to be used.
Only at the moment when F calls G. Register spills are of very
short lifetime, never beyond the end of an expression, and it's
generally pretty easy to reorder the expression so that there
are no function calls while the spills are active.
Ok, I think this is grasping for straws here. I can think of many
weird things that a compiler could do but no compiler writer would
actually do on a modern conventional machine.
I am trying to figure out what are peoples expectations of C++ beyond
providing a thread-safe library.
I've repeated it several times: I want the behavior of my
program to be defined. I want it exactly specified when I need
locking, and when I don't.
People have known the answer to this question for perhaps 30 years.
You need locking when you have multiple threads reading/writing state.
This a programmer-controllable issue that involves the construction of
libraries.
Did you see my short example. (Did it even appear? I think
some of my postings are disappearing before they reach the
moderation site.) Basically:
std::string globalButNeverModified ;
void
f()
{
// Guaranteed with Sun CC, doesn't work with g++...
if ( globalButNeverModified[ 0 ] == 'c' ) // ...
// Guaranteed with g++, doesn't work with Sun CC...
static std::string localStatic ;
}
std::string is in a library. If it was designed in such a way that it
does not work because global state is being modified, and people still
want to use it in multi-threaded applications, then it will have to be
changed. That will most-likely involve getting rid of the global
state. And yes, that will have to be universal, across all systems.
I would not expect changes to the language proper.
So basically, the C++ libraries will have to either abandon the
practice of having containers reference global state (in read/write
fashion), or decide where all the mutexes are going to go.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]