| Re: RE : Re: [eigen] Help on solving a race condition |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: RE : Re: [eigen] Help on solving a race condition
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 15 Jun 2012 16:06:33 +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=TEkbIiJ1EbI3BwfFXPmutW755FDyxvclEAMvs+2nXHE=; b=urIGCI2AJ2UiuQsOa/x/nRIF8gdiYsF+3Z2Al5T8aqjVPsleMowWcn8EetTwIALExE /7ARiZy17Csdow8zrv/qg1mO4oTjG4f9/LlUiLf9P0BzsBpz3ZD7sVmC1lzvEty1ajku Ot4/FrR5AAzmru2bUXkmSeqCWt6W/RNVGgS9SCSRXyyimQyn3N3abal1EZ+xEGScxEqD jiwd3duwSS6gwkzglq8ljUy4C+G4t7sSYjWOvz8N+0HgmCwtoG7fRmMAx22KcSgAVgkp 5K1Pw+Kl2vGRhvTQirFaGypSEQhHUBI+fYPhffFZFOWPfzZEB52W4jbfCO8pCCpPqWxq bv7A==
Indeed, it seems I looked at an old version which did not support ARM.
So that shows in the future might be able to make the initialization
function obsolete.
gael
On Fri, Jun 15, 2012 at 3:43 PM, Bastien ROUCARIES
<roucaries.bastien@xxxxxxxxx> wrote:
> Sorry for top post from my phone.
>
> My definition of portable is I think quite wide libatomic-ops is portable to
> every target of gcc >4.1
>
> Because it is used for static initialisation of static members
>
> It is a pretty safe fallback, and it is used even in embeded world because
> bohem garbage collect use it, and bohem garbage is used by free java.
>
> Bastien
>
> Le 15 juin 2012 14:15, "Gael Guennebaud" <gael.guennebaud@xxxxxxxxx> a
> écrit :
>
>
> Hi,
>
> yes I already had a look at a few atomic libs, including atomic-ops,
> but we don't have the same definition of portable. So clearly some
> architectures/systems will require a manual initialization.
> Nevertheless, we could still enable atomic ops for the few systems for
> which we are sure about the results:
>
> Windows-x86-MSVC -> _InterlockedCompareExchange intrinsic
> Linux/windows-x86-ICC-GCC -> __sync_val_compare_and_swap intrinsic.
>
> That probably already cover 95% of the use cases, so why not. I
> already have a version doing so.
>
> Using C++11 atomics is dangerous because currently the compilers
> defines __cplusplus >= 201103L even though they don't support all
> c++11 features. For instance, atomic are supported by clang only from
> the 3.1 version. So in addition to checking for __cplusplus >=
> 201103L, we also have to check the compiler name and version, and
> that's how the nightmare starts...
>
> gael
>
>
> On Fri, Jun 15, 2012 at 1:23 PM, Ilja Honkonen
> <ilja.honkonen@xxxxxxxxxxx> wrote:
>>>>> If you want ...