Actually - after thinking about it a bit more... the current code is
actually _correct_ (in that, it will always produce the correct result).
The worst that's going to happen is that we'll cache that data twice. But
the memory fences are in place and the lock is there... so the data caching
will all be consistent and there are no race-conditions.
So - it's not a complete blunder (ok, it really is) ;-)
Derek
On Wed, Mar 30, 2016 at 12:43 PM Derek Gaston <fried...@gmail.com> wrote:
>
> Yep - they are just straddling the wrong "if". They need to be straddling
> the _first_ "if". Just a dumb mistake.
>
> The timing results weren't BS... they were real... but I don't know how
> the code was working!
>
> Derek
>
>
> On Wed, Mar 30, 2016 at 12:21 PM John Peterson <jwpeter...@gmail.com>
> wrote:
>
>> On Wed, Mar 30, 2016 at 10:09 AM, Derek Gaston <fried...@gmail.com>
>> wrote:
>>
>>> Yeah - definitely egg on my face. There were so many different versions
>>> that I just screwed up the final one.
>>>
>>> I'll put in a PR to fix it.
>>>
>>> The weird thing is... I know that I ran tests on this version... and it
>>> worked fine. Must have just gotten lucky (a few million times).
>>>
>>
>> According to the Meyers paper (see pg. 12) the first memory fence might
>> need to go outside the first if-statement as well?
>>
>> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
>>
>> His example is slightly different of course, since it's for Singleton...
>>
>> --
>> John
>>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
