[jira] [Commented] (FELIX-5615) Global lock in BaseMethod.NotResolved::resolve method can cause deadlock

["Thomas Watson (JIRA)" <ji...@apache.org>]

    [ 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)