You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Julian Sedding <js...@gmail.com> on 2016/03/14 18:00:12 UTC

Deadlocks involving Felix' global lock

Hi all

I have recently analyzed two thread dumps on a framework 4.6.1 with
deadlocks involving the FelixFrameworkWiring thread calling
Felix.refreshPackages and another thread.
In both cases the FelixFrameworkWiring thread holds Felix' global lock
in Felix.refreshPackages, the other thread holds a lock in
HttpServiceImpl and ServiceRegistry, respectively. (Note, both
HttpServiceImpl and ServiceRegistry had their synchronization removed
in trunk, possibly due to similar deadlocks).

While fixing the other players in the deadlock certainly helps, I was
wondering if it would be possible to change the code inside the
framework in a way that such deadlocks are no longer possible?

I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec
talks about this situation (quoted from v5.0.0):

"Generally, a bundle that calls a listener should not hold any Java
monitors. This means that neither the Framework nor the originator of
a synchronous event should be in a monitor when a callback is
initiated. [...]"

WDYT? Any ideas on how this could be approached?

Thanks & regards
Julian

Re: Deadlocks involving Felix' global lock

Posted by Julian Sedding <js...@gmail.com>.
PS: see also FELIX-5215

On Mon, Mar 14, 2016 at 6:00 PM, Julian Sedding <js...@gmail.com> wrote:
> Hi all
>
> I have recently analyzed two thread dumps on a framework 4.6.1 with
> deadlocks involving the FelixFrameworkWiring thread calling
> Felix.refreshPackages and another thread.
> In both cases the FelixFrameworkWiring thread holds Felix' global lock
> in Felix.refreshPackages, the other thread holds a lock in
> HttpServiceImpl and ServiceRegistry, respectively. (Note, both
> HttpServiceImpl and ServiceRegistry had their synchronization removed
> in trunk, possibly due to similar deadlocks).
>
> While fixing the other players in the deadlock certainly helps, I was
> wondering if it would be possible to change the code inside the
> framework in a way that such deadlocks are no longer possible?
>
> I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec
> talks about this situation (quoted from v5.0.0):
>
> "Generally, a bundle that calls a listener should not hold any Java
> monitors. This means that neither the Framework nor the originator of
> a synchronous event should be in a monitor when a callback is
> initiated. [...]"
>
> WDYT? Any ideas on how this could be approached?
>
> Thanks & regards
> Julian