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 
[~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

Reply via email to