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>
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
>> currently held by the executing thread?
> Not at this point, at least not in the API. Do you need
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
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
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.
hpx-users mailing list