Am 13.10.2016 4:56 nachm. schrieb "Kilian Werner" <>:
> Thank you for your quick replies.
> 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?
> >> Is there a way to query the number and or nature of
> >>locks
> >> 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
> apparently.

The best way to debug this situation currently is to run the application
with --hpx:attach-debugger=exception. At some point, you'll see an output
that tells you which process threw an exception. You can then attach, for
example gdb to it, figure out which thread threw the exception: type "info
threads", the thread that sits in nanosleep is your victim. Switch to that
thread and inspect the backtrace to see where you held the lock.

> 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
> deactivatable.
> 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.
> Kind regards,
> Kilian Werner
> _______________________________________________
> hpx-users mailing list
hpx-users mailing list

Reply via email to