Kilian Just as a follow up on this. I found my code bombing out during startup with the “lock held whilst suspending” message too and I reverted a recent commit on hpx master (merge of cv race fix) and the lock error went away. You might have been unlucky to get a checkout of hpx during a possibly temporary buggy moment. (I actually did a reset --hard to the commit before the merge to solve my issue).
JB On 13/10/16 17:30, "[email protected] on behalf of Hartmut Kaiser" <[email protected] on behalf of [email protected]> wrote: >Kilian, > >> 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? > >Only if a lock was not released on scope exit. > >> >> 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. > >Would you mind creating a ticket describing your feature request? > >> 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. > >I agree, we use the disabling facilities inside HPX ourselves. > >> 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. > >Ok. I'm still not 100% convinced that this isn't a problem caused by HPX >itself. Please keep your eyes open and let us know. At the same time, I'd >be >happy to have a look at this if you were able to create a small >reproducing >test case. > >Regards Hartmut >--------------- >http://boost-spirit.com >http://stellar.cct.lsu.edu > > > >_______________________________________________ >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
