ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Semaphore action
Date Sun, 17 Jan 2016 18:26:48 GMT
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: vladisavj@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 <andrewkornev@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 <dsetrakyan@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 <andrewkornev@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.
> >  >
> >
> >
> >
> >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message