On Jun 7, 3:10 pm, Gianni Mariani <gi3nos...@mariani.wswrote:
James Kanze wrote:
...
Only GCC (v4.0 or better) will work correctly (modulo a bug on some
platforms).
Actually, all of the compilers I have access to EXCEPT g++ work
correctly here. The difference is that g++ claims that this
code is conform to its contract, the others say it isn't.
Rephrase that please.
All of the compilers I know offer a set of guarantees with
repect to threading. G++, at least on a Sparc, doesn't conform
to the guarantees it claims to offer. IMHO, it's not a serious
problem, because it does conform to the guarantees every other
compiler offers, and and it has an option that explicitly says
that it won't even try to conform to any additional guarantees.
Since thread safety is largely a question of contract, g++, by
failing to meet its contract, is not thread safe. The other
compilers meet their contract, and so are.
... If
you write code that is not conform to the contract given by the
compiler, it's not the compiler which is wrong, it's your code.
Exactly what question are you answering ?
I'm pointing out that the original question is meaningless.
G++ claims to offer more, but at least on my most common
platform (Sun Sparc, under Solaris), there is a bug in the
generated code, which means that they don't meet their own
guarantee.
Yes - I stated it's buggy on some platforms, thanks. One day
it will be fixed if there is a bug filed. I don't remember if
you filed the bug here.
I haven't, although it is related to an earlier bug that I think
I filed. You're right, however, that I should check, and refile
if it isn't being handled.
In practice, the guarantee is usually worthless anyway, since as
Jim points out, you're going to use the object, and will need a
lock for that, so you might as well just take it before the
declaration, and be done with it. A more interesting case would
be if the static were const.
Oh, I disagree. I have seen plenty of production code where this has
been an issue. The object may itself be thread safe but the
initialization is not.
I've seen it a lot with const objects, but not very often with
non-const. Implementing "thread-safety" at the object level is
generally counter productive---the granularity is too low.
...
I don't know if any compilers other than GCC try to enforce
the initialize once rule for static locals in multi threaded
environments.
I suspect that most compilers are waiting 1) to see what the
standard will require here, and 2) to see what definition might
actually be useful. Having the compiler generate
synchronization code is pessimization (paying for something you
don't need) ...
Most platforms today already support some kind of thread safe guarantees
which is already a pessimization. I doubt that a one-time startup cost
of performing a little synchronization is going to exhibit a noticeable
overhead.
The synchronization is necessary each time you enter the block.
Just to be clearer here: I agree with your basic analysis that
the compiler should do the necessary. My own measures, under
Solaris, show that acquiring a lock on a mutex isn't that
expensive, at least if there's no contention, and so there's
really no reason for the compiler to try anything more
complicated (and if g++ used a statically initialized Mutex,
instead of trying to be clever, the implementation for Sparc
would work). But that's my personal opinion. As you no doubt
know, however, there is a wide spread attitude in the C++
community of "you don't pay for what you don't use". In this
case, since there will be a lot of cases where I'll need the
user level lock anyway, and so don't need the additional
compiler lock. So requiring it is requiring users to "pay for
what they don't need." Now, you and I may agree that in this
case, the cost is negligeable, largely affordable, and quite
acceptable in return for the benefit of increased safety, but I
think you'll find that there will be some resistance to it in
certain communitees in the committee. The situation is not as
bad as it used to be, but I wouldn't like to bet one way or the
other as to what the next version of the standard will actually
require.
And I'm afraid that I didn't make it clear that I was presenting
other people's arguments, and not my own opinion. The argument
of cost that I presented definitly exists, but IMHO, it is
largely outweighed by the avantages of requiring the compiler to
synchronize correctly.
.... if I know that the first call will occur before
threading has started (often the case in my code), or if I need
a lock in the function anyway, in order to use the object.
Are you seriously saying that this is worth a few brain cycles to figure
out whether it's worth to optimize a few nanoseconds per static object
because you want to work out whether it's going to ever be needed ?
No. I'm saying that some people think so, and that "not paying
for what you don't use" has been a traditional criteria for C++.
I don't see the value proposition here. I think I've consumed
more time in crafting this sentence than my computer ever will
for synchronization overhead for local static objects it will
ever initialize by a wide margin.
It's easy to craft artificial examples where it would make a
measurable difference. I doubt that they occur much in the real
world, and I'm confident that the compiler vendors will provide
options to allow optimizing the rare and special cases where it
does.
... On
the other hand, having the compiler ensure whatever
synchronization necessary may be safer, especially where const
objects are concerned.
We agree on one thing. Cool.
I think we basically agree overall on this one point.
Realistically, however, we are not the standards committee, and
the fact that we agree doesn't really mean much.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
