[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15213405#comment-15213405
]
Vladisav Jelisavcic commented on IGNITE-642:
--------------------------------------------
Yakov,
1. I agree, though I do think we should throw IgniteInterruptedException in few
selected cases (timed/interruptible acquires) if interrupt arrives.
2. Ok, will do that.
3. Done.
4. I thought of it also, even partially implemented something similar for the
Semaphore, but for some reason discarded it in one of the latter commits.
The problem with the global waiting queue is that to enqueue a new waiter, we
need to have an additional transaction for every lock call (when there is
contention). AFAIK there is no other way to inform other nodes that there is a
new acquire pending. The way it is currently done there is only one transaction
per lock() method invocation - the one that acquires the lock.
I've adapted your code as a benchmark and it seems that this fair lock works
20-25% slower than non-fair one (will push code after I add few more tests).
Also, this whole "barging" issue is a lot less apparent if the thread doesn't
immediately attempt to acquire after release; if there is enough load inside
the loop before the lock() method is called, acquires are much more evenly
distributed (you can try it yourself by putting Thread.sleep(X) in front of the
l.lock(); bigger the X, the more evenly the lock is acquired among nodes).
Let's add a fairness parameter (like in
java.util.concurrent.locks.ReentrantLock), document it properly and let the
user decide which one to use? What do you think?
> Implement IgniteReentrantLock data structure
> --------------------------------------------
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
> Affects Versions: 1.6
> Reporter: Dmitriy Setrakyan
> Assignee: Vladisav Jelisavcic
> Labels: features
> Fix For: 1.6
>
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
