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. 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
