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

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.

Kind regards,

Kilian Werner
hpx-users mailing list

Reply via email to