Re: problem Boost libraries
On Mar 5, 7:54 am, "Yuriy Koblents-Mishke" <yur...@gmail.com> wrote:
On Mar 4, 7:25 am, "James Kanze" <james.ka...@gmail.com> wrote:
On Mar 4, 8:34 am, "Yuriy Koblents-Mishke" <yur...@gmail.com> wrote:
[snip]
Any time anyone writes to an object, all accesses to that object
must be protected. Not just the writes.
Yes.
If the
static variable is const, the switch guarantees that initialization of
the variable was completed. The subsequents reads of the variable are
thread-safe. If all static variables in function are const, it makes
the function tread-safe, IMHO.
It's not a question of const, but whether there are
modifications or not. If there are no modifications after
construction, [snip] then it would provide thread
safety.
This is const semantics. Yes, const syntax is not necessary.
Nor sufficient. The const syntax ensures bitwise const; what is
needed here is logical const, without any (logical) mutable.
But that's a lot of if's. (Generally, whenever I have
const static data, I try to arrange for it to be of POD type
with static initialization. That IS guaranteed thread safe.
But it's not always convenient.)
Inconvenient, exactly. I work with sizable const arrays, or rather a
set of arrays of different sizes, 1 to 1<<16 elements. The arrays have
a regular predetermined structure. Their elements can be listed in
code, i.e. everything can be initialized during compilation. With
smaller arrays up to, say, 256 elements it is fine. I would rather not
put arrays of 65000+ elements in my source code, though.
I do:-). Of course, I don't write them out by hand; I generate
them automatically.
I've also been known to use mmap for this sort of stuff, with
the actual data in a separate file. But of course, that
introduces the initialization problems. (One solution I often
use is simply to ensure that the function is called at least
once during dynamic initialization, before threading has
started.)
To my understanding, the switch can be implemented better, at least
for const static variables. I confronted with it while testing a small
function that contains a static const lookup table with XCode 2.4 (gcc
4.x for Mac OS X). The function was called many millions times, but
the internal static lookup table was filled only once. The thread-safe
version, compiled with a default switch, was substantially slower: in
different tests it runs 10% to 50% longer.
[snip]
Depending on what you do in the function, however, it's
normal that it runs somewhat slower. If it didn't, that would
be a very strong indication that it wasn't working at all.
To my understanding, static initialization in function may be
implemented as following:
{
static bool flag; // initialized to zero
if( ! flag )
{
initialize();
flag = true;
}
}
(actually I would expect an assembly-level jump instruction instead of
flag and check, but it does not matter).
The GCC 4.x probably adds a slow lock, as following:
{
Lock lock();
static bool flag; // initialized to zero
if( ! flag )
{
initialize();
flag = true;
}
}
Which would work fine, even under Solaris. They try to be
tricker.
while it would be better to generate:
{
static bool flag; // initialized to zero
if( ! flag )
{
Lock lock();
if( ! flag )
{
initialize();
flag = true;
}
}
}
Which doesn't work, at least not when some of the looser memory
models are active.
seehttp://www.cs.wustl.edu/~schmidt/editorial-3.html
Which is out of date. The idiom proposed has since been proven
not to work, at least as is. It can be made to work at the
generated code level, by introducing various additional machine
instructions (fences, membars, or whatever---it depends on the
architecture), and being careful about the order the code is
generated, so g++ could use it, if they wanted. At least under
Solaris on a Sparc, however, I'm not sure that once all the
additional instructions have been inserted, that the code would
be any faster than the initial version. About the only real
expense in acquiring a non-contested lock is that associated
with the membar instructions (under Solaris, on a Sparc---I
can't say generally what the situation is). And without the
membar instructions, you can't be sure that other threads see
the correct value of flag; another thread could see flag true
before all of the writes in initialize became visible to it.
I have a minimal experience in multithreading, but, to my
understanding, since the technique was proposed by Douglas Schmidt in
1996, it became a standard idiom. Implementation is easy, and
overheads are negligible
The technique was in fact proposed by Vlissides (as Doug himself
states), and was very rapidly widely diffused. And analysed,
which revealed the flaws in it. (See e.g.
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.
The actual article concerns Java, but the issues are exactly the
same in C++.)
[snip]
Since it's not portable
anyway, however, the best solution is probably to turn it off,
and write your code so that it will work portably.
I would say that is kind of portable, or at least more standard
conforming than when the switch is not used.
Other compilers don't offer it. If you ever count on porting
your code to other compilers, it's best not to use it.
The standard's committee is discussing the issue, but I don't
know off hand what their current thinking is. In favor, of
course, is the fact that the compiler can generate the extra
machine instructions which might be needed, so that it
potentially costs less than if you try to manage it by hand.
Against is the fact that it does introduce some excess costs,
albeit not very high, and these costs will be there whether you
use the facility or not, which violates the "you don't pay for
it if you don't use it" philosophy.
C++ expects that static
variables will be initialized the very first time the function is
called. C++ expects also that the variables are completely initialized
when the subsequent code will be running. C++ does not know about
threads.
However, the switch is not implemented properly on Mac (my experience)
and on Sparc (your experience). I also would rather avoid it
currently.
How is it not implemented correctly on a Mac? Just that it is
too slow? Or that it really doesn't work---on a Sparc, it
doesn't actually guarantee that the initialization will only be
executed once, and if the Sparc has real-time options activated,
it may introduce dead locks into the code (at least in the 32
bit version---the 64 bit version seems correct in this regard,
at first reading, although it needs some extra membar
instructions to ensure that the initialization is only executed
once).
--
James Kanze (GABI Software) email:james.kanze@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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]