You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Denis Chudov (Jira)" <ji...@apache.org> on 2022/12/14 13:05:00 UTC

[jira] [Assigned] (IGNITE-18316) Reusing same waiter for multiple acquisitions can lead to races due to future rewrite outside of synchronized section

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

Denis Chudov reassigned IGNITE-18316:
-------------------------------------

    Assignee: Denis Chudov

> Reusing same waiter for multiple acquisitions can lead to races due to future rewrite outside of synchronized section
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-18316
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18316
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Denis Chudov
>            Assignee: Denis Chudov
>            Priority: Major
>              Labels: ignite-3
>
> Under IGNITE-18294 reusable waiters in heap lock manager have been done. Each waiter has a {{fut}} field, storing lock future, which is completed when waiter can be locked, converting all of its lock intentions into actual locks. Only one future for all intentions can exist, this means that it will be completed when supremum of all lock intentions can be acquired. As the lock mode for the waiter can be upgraded multiple times, lock future can be created several times for the waiter, rewriting {{fut}} field.
> Waiter's thread safety is provided by synchronized section on the mutex which is waiters collection for the key. Meanwhile, lock future should be completed outside of this mutex, as there may be long running tasks created for {{thenComplete}} of this future. These tasks must be done outside of the mutex, otherwise performance of the lock manager will be poor.
> Obviously, assuming that future field can be rewritten inside of mutex at any time, we can't complete it safely outside of mutex.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)