Re: IgniteSemaphore methods semantics

2017-08-10 Thread Valentin Kulichenko
If this is true, I think it should be fixed. availablePermits() returning
number of acquired permits sounds very confusing.

-Val

On Thu, Aug 10, 2017 at 7:38 AM, Andrey Kuznetsov  wrote:

> Hi, igniters!
>
>
>
> As IgniteSemaphore's javadoc states,
>
>
>
> "Distributed semaphore provides functionality similar to {@code
> java.util.concurrent.Semaphore}."
>
>
>
> At the same time method semantics of current implementation is inverted,
> i.e. acquire() decrements internal semaphore count and release() increments
> count. Then newlyCreatedSemaphore.acquire() call blocks until some other
> thread calls release(), and it looks confusing.Also, availablePermits()
> returns permits acquired so far, that is, semaphore count.
>
>
>
> Another difference is unbounded nature of IgniteSemaphore implementation,
> while java.util.concurrent.Semaphore is bounded.
>
>
>
> I think we are to do one of the following:
>
>
>
> - Document uncommon IgniteSemaphore semantics properly
>
>
>
> or
>
>
>
> - Change its semantics to conform java.util.concurrent counterpart.
>
>
>
> --
>
> Best regards,
>
>   Andrey Kuznetsov.
>


IgniteSemaphore methods semantics

2017-08-10 Thread Andrey Kuznetsov
Hi, igniters!



As IgniteSemaphore's javadoc states,



"Distributed semaphore provides functionality similar to {@code
java.util.concurrent.Semaphore}."



At the same time method semantics of current implementation is inverted,
i.e. acquire() decrements internal semaphore count and release() increments
count. Then newlyCreatedSemaphore.acquire() call blocks until some other
thread calls release(), and it looks confusing.Also, availablePermits()
returns permits acquired so far, that is, semaphore count.



Another difference is unbounded nature of IgniteSemaphore implementation,
while java.util.concurrent.Semaphore is bounded.



I think we are to do one of the following:



- Document uncommon IgniteSemaphore semantics properly



or



- Change its semantics to conform java.util.concurrent counterpart.



--

Best regards,

  Andrey Kuznetsov.