[
https://issues.apache.org/jira/browse/IGNITE-18316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18316:
----------------------------------
Description:
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 is not thread safe and all work with it should be done under mutex.
Meanwhile, lock future should be completed outside of this mutex, as there may
be long running tasks created for {{thenComplete}} of this future. This 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.
was:tbd
> 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
> 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 is not thread safe and all work with it should be done under mutex.
> Meanwhile, lock future should be completed outside of this mutex, as there
> may be long running tasks created for {{thenComplete}} of this future. This
> 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)
