Vladisav,
It would be great if you could implement the enhancements!
And while we're at it, here's something else I'd like us to consider. The
proposed API only gets us half way there: there is no longer a blocking wait
for the permit, but the action must be blocking. I really think it should be
possible to do the whole thing asynchronously including the action and release
of the permit. (In fact, this is what I need for my project. In 7.4, I was able
to implement this feature using just the public APIs, but I'd really like to
drop that code and start using the Semaphore API.)
For example, upon the permit acquisition, the action could fire off a
distributed compute and rather than block waiting for the results to come back,
it would simply return the future provided by Ignite's withAsync(). The
semaphore implementation would not release the permit immediately upon the
action return. Instead, it'd do so only when the action future completes.
Here's how the API might look like:
<T> IgniteFuture<T> acquireAndExecuteAsyncAction(Callable<IgniteFuture<T>>
action);
This API makes it possible to execute a protected action with no blocking
whatsoever! It's a lot more efficient, reduces the pressure on Ignite's thread
pools and prevents thread starvation, and so on.
Regards
Andrey
> Date: Sun, 17 Jan 2016 10:40:53 +0100
> Subject: Re: Semaphore action
> From: vladis...@gmail.com
> To: dev@ignite.apache.org
>
> It does sounds like a useful addition,
> and I believe it could be implemented easily.
> I can do it if the community agrees on changing the API of the Semaphore.
>
> Best regards,
> VJ
>
> On Sun, Jan 17, 2016 at 5:53 AM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
> > Dmitriy,I don't believe it makes sense to have the action execute
> > remotely. At least I didn't think of it.In my mind, the action is always
> > local (that's the reason I suggested the Java's Callable in the API and not
> > serializable IgniteCallable, in the first place). What the action does is
> > entirely up to the user. One could fire off a remote compute if that's what
> > one wants.I hope I make myself clear.ThanksAndrey
> > _____________________________
> > From: Dmitriy Setrakyan <dsetrak...@apache.org>
> > Sent: Saturday, January 16, 2016 7:54 AM
> > Subject: Re: Semaphore action
> > To: <dev@ignite.apache.org>
> >
> >
> > Andrey,
> >
> > In general this seems like a good addition. However, I do not understand
> > how you can specify an executor, given that execution could happen
> > remotely. Can you please clarify?
> >
> > D.
> >
> > On Fri, Jan 15, 2016 at 1:00 PM, Andrey Kornev <andrewkor...@hotmail.com>
> > wrote:
> >
> > > Hi there,
> > >
> > > The Semaphore feature was a great addition to Ignite's synchronization
> > > primitive toolkit. I'd like to propose an enhancement to make Semaphore
> > API
> > > even more useful.
> > >
> > > My biggest complaint about the current API is its blocking nature. For
> > > example, the only way to acquire a permit is by using the blocking
> > > acquire() method (tryAcquire() is not very useful in the cases when you
> > > MUST acquire before you can proceed). I believe that in the 21st century
> > > blocking APIs is anachronism. :))) It's a bit embarrassing even. I'm
> > sure
> > > Ignite can do better than that! :)
> > >
> > > Usually a permit acquisition is followed by an action, followed by a
> > > release of the permit. I propose a simple enhancement to the Semaphore
> > API
> > > that will reduce the boilerplate and make it possible to do all of that
> > > asynchronously! The new method might look like this:
> > >
> > > <T> IgniteFuture<T> acquireAndExecute(Callable<T> action);
> > > <T> IgniteFuture<T> acquireAndExecute(Callable<T> action, Executor
> > > executor);
> > >
> > > (The name could be improved, of course...) The first method would
> > > immediately return a future to be later completed by the action's
> > result.
> > > The action will be executed on a thread from the Ignite's public thread
> > > pool once a permit has been acquired. Optionally, the user could
> > specify a
> > > different executor using the second signature.
> > >
> > > Would the community be interested in such enhancement?
> > >
> > > Thanks
> > > Andrey
> > >
> > > PS. A subject for a separate discussion, but I believe that in the next
> > > major release Ignite should just drop the clumsy withAsync() API and
> > make
> > > all blocking calls explicitly async by returning a future. In my
> > opinion it
> > > would greatly simplify the API and make it more modern. Besides, I'm
> > pretty
> > > sure that internally Ignite already creates futures for pretty much
> > most of
> > > the API calls, so it should not cause any performance issue.
> > >
> >
> >
> >
> >
> >
