>One of our threads holds a lock, then requests another but this second one is 
>already locked, so it tries to suspend, which is not allowed while holding a 

suspending whilst holding a lock can lead to deadlocks. 

>However the task CommunicationHandler::expectImage that yields this error 
>should hold no locks prior to requesting the spinlock that causes the suspend.
If you are 100% certain that you hold no locks, then it might be a bug. Are you 
using the master branch of HPX or an older one. I had a number of issues with 
locks that seem to have gone away in recent times.

>Is my interpretation of the occurring events that lead to this error correct?

>For what purpose is it illegal to suspend while holding a lock?
Unless you can state with 100% certainty that there is no possibility of task A 
taking lock A and then suspending whilst waiting for B, when task B takes lock 
B and suspends waiting for A - and any combination of A waiting for C that 
wiats for D ,E, F etc and leading back to B, then it is illegal to suspend when 
holding a lock.
Assume that it is always illegal to suspend whist holding a lock, then you'll 
be safe.

>Is there a way to query the number and or nature of locks currently held by 
>the executing thread?
Not sure, but you can look at the code that ignore while locking leads back to 
and there might be a hook there somewhere

>Different tasks spawned by (possibly remote) asynchronous calls may be run in 
>the same hpx worker thread... is it possible for a threads different tasks to 
>influence each other regarding something like held locks?
when one of the tasks takes a lock, others will block if they try to. it's 
business as usual as far as locking is concerned.

Not sure if I helped

hpx-users mailing list

Reply via email to