Thanks! I'm traveling at the moment so I hadn't gotten around to it.
We'll double check to see if that is sufficient when I get back (like
Thursday).
Thanks again!
Derek
Sent from my iPad
On Aug 19, 2013, at 5:50 PM, Roy Stogner wrote:
>
> On Fri, 16 Aug 2013, Derek Gaston wrote:
>
>> I won'
On Fri, 16 Aug 2013, Derek Gaston wrote:
> I won't have access to either of those machines to do more testing
> until next week.
>
> For now, I vote for removing those locks as they are unnecessary.
Apologies if I stepped on your toes, but I just went ahead and pushed
a patch which removed the m
On Aug 17, 2013, at 12:35 AM, Derek Gaston wrote:
> Pthread locks work by being 0 in their unlocked state and anything
> else when they are locked. I can only guess that the constructor for
> those mutexes hasn't yet been called to set the initial value of the
> lock... therefore it's waiting t
A couple of things:
1. This only happens with pthreads (ie it doesn't happen with TBB).
2. I can confirm that it is the same symptom on the Intel Phi card.
3. I can confirm that it is alleviated by commenting out those
scoped_lock lines (for both machines).
Pthread locks work by being 0 in t
On Fri, 16 Aug 2013, Derek Gaston wrote:
We're seeing hard locks on some machines in Singleton::Setup::Setup()!
The problem is that it's trying to create a scoped_lock using a mutex that is
defined in that file.
Apparently that mutex is not guaranteed to have been initialized at the point
w
Guys,
We're seeing hard locks on some machines in Singleton::Setup::Setup()!
The problem is that it's trying to create a scoped_lock using a mutex that
is defined in that file.
Apparently that mutex is not guaranteed to have been initialized at the
point where we're calling that function (or som
