|Re: [eigen] Help on solving a race condition|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Help on solving a race condition
- From: Jim Bosch <talljimbo@xxxxxxxxx>
- Date: Thu, 14 Jun 2012 00:05:15 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=g/rdbzk+VR+QdDkuCjbdKUSHlwelvoiLUMwCpSA+dR8=; b=t/nlyBqMf4VtJNJyQstr3oZFsLh1t/kAVjBeINdclZ1vCF8JI23h3XmDOluW/03q3Z sYMHb47HOfOSu0LyWBuQHCJAaztxDMoKuv6ADlX1ZmQIy1i5k52PWsDAeyTqMDJIqN0W FMU+9xwEgBJJWGXMSx+MctlrShx3PoSr9h1exNe8jJyg/YRZqSF4fFYArJcWrF1mFm1J hMwukvNDrT7C3Pje8oYTd1e0f05W9DaUYAI2DOcUaYIaVy88rjSA3WfiP2Usd1lQOKVn Z4mcM1Ajhrdfr1HPqNOTCi95NQaBg2zcQmIfRheqrK9DKx8JKpXYCSNUvO/gCXw4b8RK 9qDw==
I'm a little surprised the configure-time solution that was brought up
early in this thread was dismissed so quickly. Sure, it's nice to be
able to use Eigen's headers as-is with no build at all today, but a
machine-generated header file that contains these values as true
constants wouldn't be such a terrible thing to add.
I'd certainly personally much prefer to have to run a script to generate
a header when I install Eigen over having to call a function every time
I use Eigen!
On 06/11/2012 04:00 PM, Gael Guennebaud wrote:
Thanks a lot, that's the kind of explanations I expected.
So I'm afraid the only truly portable and robust solution will be to
add an initialize function.
On Mon, Jun 11, 2012 at 7:43 PM, John Tytgat <John.Tytgat@xxxxxxxx> wrote:
There is no guarantee that the "initialized = true" gets seen by another
thread after the update to "m_l1CacheSize" or "m_l2CacheSize" gets seen by
that thread. The order of the stores can be differently perceived by the
other thread than what the first thread did. And this because your compiler
can have rearranged your "initialized" store before the stores to
"m_l1CacheSize" and "m_l2CacheSize". Moreover, another store rearrangement
can happen at runtime in the memory system between CPU, all its caches and
Or it could very well be that updates to "initialized", "m_l1CacheSize" or
"m_l2CacheSize" are never seen by other threads (as e.g. the update sticks
at a certain cache level which is not shared by other threads).
Before someone suggests to additionally use the volatile keyword, volatile
will make the compiler respect the store order but your memory system can
still do reordering (cfr.