You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Ozerov (JIRA)" <ji...@apache.org> on 2016/04/28 09:48:13 UTC
[jira] [Updated] (IGNITE-1346) Implement striped spin busy lock.
[ https://issues.apache.org/jira/browse/IGNITE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladimir Ozerov updated IGNITE-1346:
------------------------------------
Fix Version/s: (was: 1.6)
1.7
> Implement striped spin busy lock.
> ---------------------------------
>
> Key: IGNITE-1346
> URL: https://issues.apache.org/jira/browse/IGNITE-1346
> Project: Ignite
> Issue Type: Task
> Components: general
> Affects Versions: 1.1.4
> Reporter: Vladimir Ozerov
> Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> We have lots of places in code which require "busy" state semantics:
> 1) Multiple readers access some resource concurrently setting "busy" state.
> 2) At some point a single writer comes, prevents all further readers from accessing the resource, and blocks until all other previous reades are out.
> Currently we do that using either GridBusyLock or GridSpinBusyLock. The first one is based on ReentrantReadWriteLock and the second one is based on GridSpinReadWriteLock.
> Both implementation have the same performance characteristics, being limited by CPU bus bandwidth when trying to update atomically a shared variable.
> Better approach is to "stripe" the lock across multiple variables this minimizing contention between threads. That is, in ideal case each thread increments/decrements his own variable without any contention. Writer will have to iterate over all these variables and block on each until all readers are out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)