Re: [eigen] Help on solving a race condition

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

On Thu, Jun 14, 2012 at 6:05 AM, Jim Bosch <talljimbo@xxxxxxxxx> wrote:
> 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.

as I said, this is not an option because these values depend on the
underlying hardware. So such an approach makes impossible to
distribute configured version of Eigen nor binary that uses Eigen.

> 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!

Note that this function will have to be called only in the case the
user code is multi-threaded.


cheers,
gael


> Jim
>
>
>
>
>
> 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.
>>
>>
>> Gael.
>>
>>
>>
>> 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
>>> main memory.
>>>
>>> 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.
>>>
>>> http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/).
>>>
>>> John.
>>>
>>>
>>>
>>
>>
>
>
>
>