Re: [eigen] Help on solving a race condition

[John Tytgat <John.Tytgat@xxxxxxxx>]

On 6/11/2012 7:17 PM, Gael Guennebaud wrote:
> Hi,
>
>
> After some more thoughts, I'm finally unsure about the thread local
> storage solution. Indeed, this solution seems to be quite fragile
> because it requires compiler/platform specific code.
>
> So I propose to simply rewrite the code like this:
>
>   static std::ptrdiff_t m_l1CacheSize = 0;
>   static std::ptrdiff_t m_l2CacheSize = 0;
>
>   static bool initialized = false;
>   if(!initialized)
>   {
>    m_l1CacheSize = manage_caching_sizes_helper(queryL1CacheSize(),8 * 1024);
>    m_l2CacheSize =
> manage_caching_sizes_helper(queryTopLevelCacheSize(),1*1024*1024);
>    initialized = true;
>   }
>
> With this solution it might happen that m_l1CacheSize is overwritten
> at the same time it is read by another thread, but since it gets
> overwritten by the same value this cannot be an issue, right?
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.