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, "hpx-users-boun...@stellar.cct.lsu.edu on behalf of
Hartmut Kaiser" <hpx-users-boun...@stellar.cct.lsu.edu on behalf of
hartmut.kai...@gmail.com> 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
>hpx-users@stellar.cct.lsu.edu
>https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

_______________________________________________
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Reply via email to