Re: problem Boost libraries
On Mar 4, 8:34 am, "Yuriy Koblents-Mishke" <yur...@gmail.com> wrote:
On Jan 29, 4:36 pm, "James Kanze" <james.ka...@gmail.com> wrote:
[...]
The presence or absence of this switch does not make a function
using local static variables thread safe.
[snip]
Well, it depends.
I guess that writing to static variables are guarded by lock.
Any time anyone writes to an object, all accesses to that object
must be protected. Not just the writes.
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, and the implementation of the option actually
worked (it doesn't on a Sparc), then it would provide thread
safety. 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.)
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.
If you try it on a Sparc, under an OS which supports real-time
threading (Solaris doesn't, at least in the configurations I
usually use), the process can actually deadlock, and never
finish. 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.
I don't understand why they try to do things so fancy. At least
on Posix machines, it's sufficient to stuff the code into a
pthread_once (which leaves it up to the authors of the OS to
make it efficient).
For the moment, I would very much recommend not using this
option (which is active by default, I think) on a Sparc. I've
not verified on other platforms. 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.
--
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! ]