ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Semaphore action
Date Mon, 18 Jan 2016 11:28:24 GMT
I like the idea. Couple of comments though.

I would leave only <T> IgniteFuture<T> acquireAndExecute(Callable<T>
action); Overload with executor can be omitted because callable
implementation can use any executor. As far as moving acquire logic to
another thread pool - I think we'd better go without it same as for any
other Ignite operations. Andrey, what was the pool intended for?

This T> IgniteFuture<T> acquireAndExecuteAsyncAction(Callable<IgniteFuture<T>>
action); can be implemented with  <T> IgniteFuture<T>
acquireAndExecute(Callable<T> action); where T is IgniteFuture for
operations initiated and returned by callable. Makes sense?


--Yakov

2016-01-18 0:39 GMT+03:00 Andrey Kornev <andrewkornev@hotmail.com>:

> Just to clarify, 7.4 below refers to GridGain 7.4, which is Ignite 1.4.
>     _____________________________
> From: Andrey Kornev <andrewkornev@hotmail.com>
> Sent: Sunday, January 17, 2016 10:27 AM
> Subject: RE: Semaphore action
> To:  <dev@ignite.apache.org>
>
>
>                    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