Re: [eigen] Help on solving a race condition

[ Thread Index | Date Index | More Archives ]

On 6/11/2012 7:17 PM, Gael Guennebaud wrote:

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;
   m_l1CacheSize = manage_caching_sizes_helper(queryL1CacheSize(),8 * 1024);
   m_l2CacheSize =
   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.


Mail converted by MHonArc 2.6.19+