[
https://issues.apache.org/jira/browse/IGNITE-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1346:
------------------------------------
Description:
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.
> 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: ignite-1.4
>
>
> 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)
