[ 
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119832#comment-16119832
 ] 

Alexey Kuznetsov commented on IGNITE-642:
-----------------------------------------

After a thread signals on a condition, another thread, waiting on the same 
condition(with the same name) doesn't awakens until first trhead unlocks the 
lock.
[~vladisav] admitted, it is desireable behavior for ignite lock implementation. 

As it stated in javadoc for Condition.await() : 
"In all cases, before this method can return the current thread must re-acquire 
the lock associated with this condition. When the thread returns it is 
guaranteed to hold this lock."
So , before sleeping thread awakens(and necessarily take a lock), the lock must 
be released by first lock.

In current implementation of GridCacheLockImpl, signal is transferred to 
cluster nodes when lock is released.


> 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.4.14#64029)

Reply via email to