Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Thu Feb 03 2005 11:44 pm

Marcin 'Qrczak' Kowalczyk wrote:

> Giancarlo Niccolai <searchforme@ingoogle.com> writes:
> 
>>> Simply because the C++ standard is quite specific in that static
>>> function local variables (non POD) must be initialized exactly once
>>> on the *first time* that control passes through the variable. All
>>> we're doing here is enforcing this requirement.
>>
>> Perfect. So, what's the problem in having a mutex built before you
>> first need the thing that are willing to use that mutex? Why do a
>> compiler having this for you should make your program better?
> 
> Because it would change various instances of code written with no
> threads in mind from unsafe to safe to use with threads.
> 

That is utterly impossible. This also replies to your previous mail. Also,
MT programs have requirements that ST do not have, like i.e. waiting for
other threads to have set up things, or prepearing things for other
threads. As "other threads" do not exist in ST, there is no way by which a
GENERIC MT program can be made safe as a ST program may be; also, an ST
program that is going to run under MT... will still be ST until you start a
thread, and so, it will be ALREADY safe as it was before until you change
its behavior, and hopefully, you change the behavior knowing what you are
doing (and if you don't the program will break regardless any constraint
you put on it).

So, again, ppl, the point is just pointless.

And no, Marcin, C++ is not like and will never be like a scripting language
where the VM is in control of the exact execution steps of the running
program. This because that control costs; i.e. it costs 400 times slower
than C in perl, 600 in Python and 1000 to PHP. OTOH, that leak of control
costs in C/C++ in terms of higher development times and higher skill
demands, but that's fine: is a trade off. If I want a thing that does a
little threading safe for me, I get Python, produce fast and run slow. If I
want a thing that goes 600 times faster, I go for C/C++ and I take care of
what is locked, where and why. And I want this to stay this way. If you
think that the "C++" programming language needs "more protection", go for
C#; they already have done it, it's fast (25-50 times or so slower than C)
and it is CORRECTLY protected on this issues. Now, unless you want to
protect C++ the same way, slowing it down by 50 times, you are not going to
protect a generic ST program being hurled into MT with mindless rage, and I
don't want you to slow down C++ that much just because you (I mean the
general audience, of course, Marcin) don't want to spend 1 second of your
life (again, not yours, I mean the generic audience) in figuring how to
start the threads in the right place. 

Gian.

.