[
https://issues.apache.org/jira/browse/FELIX-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15969280#comment-15969280
]
Thomas Watson commented on FELIX-5615:
--------------------------------------
I found something suspicious in the method BindMethod::doFindMethod which gets
called by BaseMethod::findMethod while holding the NotResolved.INSTANCE global
lock.
In the method BindMethod::doFindMethod it does change the state of the field
BindMethod::m_paramTypes and then returns the found Method object. So it would
appear this lock is making the change in state for the following atomic:
BindMethod::m_paramTypes
BaseMethod::m_method
BaseMethod::m_state
I think we should look at protecting this atomic operation in a different way.
I am pretty sure the global lock is not needed here while setting the state of
these fields. But I also would like to avoid holding any locks between the
calls to BaseMethod::findMethod and BaseMethod::setMethod. To do that I would
return a composite object back from BaseMethod::findMethod and
BaseMethod::doFindMethod that contained the method and any other specific
object the subclass needs when the method is ultimately set. This way we can
synchronize on BaseMethod::setMethod to make the operation atomic.
Here is an initial attempt at doing this
https://github.com/tjwatson/felix/commits/felix-5615
> Global lock in BaseMethod.NotResolved::resolve method can cause deadlock
> ------------------------------------------------------------------------
>
> Key: FELIX-5615
> URL: https://issues.apache.org/jira/browse/FELIX-5615
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Reporter: Thomas Watson
>
> See eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=515215
> org.apache.felix.scr.impl.inject.BaseMethod.NotResolved has a single instance
> which is held by the static field NotResolved.INSTANCE
> This means that the synchronized method NotResolved::resolve holds the global
> lock on this NotResolved.INSTANCE object. It is unclear why this complete
> method needs to be synchronized. But is is also unclear why it has to be a
> global lock also. Is this by design? or a consequence of some refactoring
> that made this method act on a global lock?
> This is causing issues because while calling BaseMethod::findMethod
> reflection is done which can then trigger additional class loads. These can
> then result in lazy activation to be triggered. There is a whole set of
> deadlock situations that could happen during lazy activation while this
> global lock is being held.
> I have not studied the code in detail, but it appears BaseMethod:findMethod
> is stateless and it is unclear why we need to hold a lock between calls to
> BaseMethod::findMethod and BaseMethod::setMethod (let alone a global lock).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
