felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Sedding <jsedd...@gmail.com>
Subject Deadlocks involving Felix' global lock
Date Mon, 14 Mar 2016 17:00:12 GMT
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

Mime
View raw message