ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
Date Tue, 28 Nov 2017 12:03:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrey Kuznetsov updated IGNITE-6186:
-------------------------------------
    Description: 
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing two adjacent
non-root listener nodes from list simultaneously by calling {{unregisterWaiter()}}. Then data
race is possible: one of these listeners can survive its removal. If the listener is a thread
waiting for completion in {{get0()}} then this race leads at worst case to 1 extra call to
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an arbitrary listener,
and its {{apply()}} will be called twice.

  was:The method is not thread-safe unless actual parameter is currentThread.


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> -------------------------------------------------------------------
>
>                 Key: IGNITE-6186
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6186
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 2.1
>            Reporter: Andrey Kuznetsov
>            Assignee: Andrey Kuznetsov
>            Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are removing two adjacent
non-root listener nodes from list simultaneously by calling {{unregisterWaiter()}}. Then data
race is possible: one of these listeners can survive its removal. If the listener is a thread
waiting for completion in {{get0()}} then this race leads at worst case to 1 extra call to
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an arbitrary listener,
and its {{apply()}} will be called twice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message