> I am not 100% certain that the suspending thread is not
> holding any locks, trusting your check something seems to
> slip my attention.
> However I am not requesting that much locks and each of
> them with the std::lock_guard<hpx::lcos::local::mutex>
> l(mtx); syntax.
> This results in all held locks being requested in a method
> on the stack trace, since no intermediately called methods
> that already finished execution can omit any locks beyond
> their scope... right?
Only if a lock was not released on scope exit.
> >> Is there a way to query the number and or nature of
> >> currently held by the executing thread?
> > Not at this point, at least not in the API. Do you need
> >this functionality?
> This conflict between my missing observation of any held
> locks and the check firing is the motivation for querying
> all locks held in the current context.
> I don't really need this functionality for functionality
> of the application, but it would come in handy during
> debugging, since I somehow lost track of my locks
Would you mind creating a ticket describing your feature request?
> Thank you for explaining the decision to check for any
> locks before suspending. While I think the decision is
> very plausible, it's still a good thing it's so flexibly
I agree, we use the disabling facilities inside HPX ourselves.
> Thank you for making it clear, that no two hpx-threads can
> have any influence on each other regarding locks. I am
> therefore limiting my search for untracked locks to the
> methods on the stacktrace.
> Btw we compiled the used hpx version a few days ago from
> the master branch.
Ok. I'm still not 100% convinced that this isn't a problem caused by HPX
itself. Please keep your eyes open and let us know. At the same time, I'd be
happy to have a look at this if you were able to create a small reproducing
hpx-users mailing list