Am 13.10.2016 4:56 nachm. schrieb "Kilian Werner" <[email protected]>: > > 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 > [email protected] > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
