|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: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 14 Jun 2012 09:37:46 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=NuV9WrSJgqBNCEEtVT3E1OgBC4pE1jCL82tOsRIglRc=; b=KiexunOR69NwtohES2nzdJrWIHuo0kMt+hW7ew+mk6+nkH3w6KQ7tASnQ/ZERwkmnL fzY4OZ28pQR5Kl6U3somXvXvMDoGfCqvPh7nerEOZJRGmX/zwpRpNC3LC7A/Qdxpg9sp 2Xjtt1WuZSH+aA3Z24Bsr0bzzNf6YzHvetYLlFINGgVvVAaT/QXCCRD+kL2+Shg29yAV HPhpVK8DGcxf1lY7iw1ijzQ89hIuJPgzGl31OqMLSyWAqFGq6FCbWQmRodCDNR0FTOKL VW28SfaLC1jaMSH1Agd5XPaY//gcee7+Yh0sUgh3ErpyHrDCzFvTp2JcWgB9e4SciUIw irMQ==
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
Note that this function will have to be called only in the case the
user code is multi-threaded.
> 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
>>> 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
>>> can have rearranged your "initialized" store before the stores to
>>> "m_l1CacheSize" and "m_l2CacheSize". Moreover, another store
>>> can happen at runtime in the memory system between CPU, all its caches
>>> main memory.
>>> Or it could very well be that updates to "initialized", "m_l1CacheSize"
>>> "m_l2CacheSize" are never seen by other threads (as e.g. the update
>>> at a certain cache level which is not shared by other threads).
>>> Before someone suggests to additionally use the volatile keyword,
>>> will make the compiler respect the store order but your memory system can
>>> still do reordering (cfr.