[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epsilon-dev] Automatic substitution for parallel operations
|
Hi Dimitris,
I suppose there are multiple ways to detect whether parallel execution
is nested, and indeed one possible solution may be to see if the
current FrameStack has a reference to the parent FrameStack, however if
for whatever reason the main thread's FrameStack is initialised with a
parent (perhaps in the future) then this would break the assumption.
Another solution would be to check the name of the thread and if it
matches the one set by EoLThreadFactory then we know we're nested.
However if parallel execution is being performed through a different
means e.g. parallel streams then the thread will be from the common
pool. The current solution of checking whether the calling thread is
the initial one seems to be working, though it is beneficial to have
multiple methods as a fallback.
I have encountered a number of interesting issues with making this
seemingly small change of automatic parallel operations, which has
required quite a bit of refactoring to the parallel infrastructure,
however I think this has been worthwhile as it has made the API
cleaner. It also helped to illustrate the shortcomings of the initial
design and highlight a few bugs which (I hope!) have now been fixed.
Given that the tests are passing, would it be OK to merge these
changes?
Also regarding the mailing list, I contacted the webmaster last year
but I've not found a solution yet.
Thanks,
Sina
On Mon, 2019-04-15 at 12:29 +0100, Dimitris Kolovos wrote:
> Sina,
>
> Please see comments below.
>
> On Sun, 14 Apr 2019 at 01:52, Sina Madani <sinadoom@xxxxxxxxxxxxxx>
> wrote:
> > Hi Dimitris,
> >
> >
> >
> > Thank you for your encouragement and pointing that out! I haven’t
> > yet changed the logic of detecting parallelisation to checking the
> > thread name yet – currently it’s a case of incrementing and
> > decrementing an integer but since we only support a nesting level
> > of 1 then it can theoretically be simplified to that. I suppose one
> > possible solution is to have a static initialiser so that when
> > Epsilon is loaded we cache this top level thread name, which can be
> > identified in subsequent calls through a static method e.g.
> > org.eclipse.epsilon.eol.context.concurrent.IEolContextParallel.isTo
> > pLevelThread(). I will try to write a plugged-in test to verify
> > that this is a viable approach.
> >
> >
>
> Is there any chance you can detect this by looking at the framestack?
>
> > Another point I forgot to mention: replacement of sequential for
> > parallel currently only happens if the context is already parallel,
> > which is usually only the case if the user explicitly selects a
> > parallel implementation (e.g. EolModuleParallel for EOL) from the
> > “Advanced” tab. It is for this reason that explicit parallel
> > operations exist: invoking a parallel operation from plain
> > EolContext copies the state into an EolContextParallel before
> > executing the op (this conversion is performed every time, since
> > the context is discarded after the op has returned). I envisage
> > that in the future perhaps all modules and contexts will extend
> > EolModuleParallel / EolContextParallel and be the default, which
> > would eliminate the need for these steps.
> >
>
> OK - this makes sense.
>
> > P.S.: I’m still not receiving mails from the mailing list, hence
> > the copy-paste below.
> >
>
> Have you already reported this to the Eclipse webmaster?
>
> Cheers,
> Dimitris
>
> > Thanks,
> >
> > Sina
> >
> >
> >
> > -----------------------------------------------------------------
> > -----------------------------------------------------------------
> > -------------------------------------------------------
> >
> > From: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>
> > Date: Sat, 13 Apr 2019 21:09:01 +0100
> > Delivered-to: epsilon-dev@xxxxxxxxxxx
> >
> > Hi Sina,
> >
> >
> >
> > Auto-detecting when parallel operations can be safely used would be
> >
> > very useful indeed! I'm only wondering whether
> >
> > Thread.currentThread().getName().equals(âmainâ) is a reliable way
> > of
> >
> > determining whether we're in a "top-level" thread. Does this hold
> > when
> >
> > an Epsilon program is ran through the Eclipse-based development
> > tools
> >
> > or e.g. through Tomcat? [1]
> >
> >
> >
> > Cheers,
> >
> > Dimitris
> >
> >
> >
> > [1] https://www.eclipse.org/epsilon/doc/articles/egl-server-side/
> >
> >
> >
> >
> >
> > From: Sina Madani
> > Sent: 13 April 2019 20:18
> > To: Epislon Project developer discussions
> > Subject: Automatic substitution for parallel operations
> >
> >
> >
> > Hi everyone,
> >
> >
> >
> > I’ve recently been experimenting with a way to eliminate the need
> > for users to explicitly specify when to use parallel operations.
> > The only reason to avoid using parallel operations, except for the
> > rare case where selectOne must return the first element which
> > matches the criteria in an ordered collection and where global
> > state is mutated, is to avoid nesting. However since
> > IEolContextParallel can already detect illegal nesting and throw an
> > exception, would it not make sense to only apply parallelisation
> > when there is no nesting?
> >
> >
> >
> > More concretely, the only change required is to
> > AbstractOperation.getOperationFor as shown in [1]. From the user’s
> > point of view, there would be three ways of invoking an operation.
> > To demonstrate, consider “select” as an example:
> >
> >
> >
> > .parallelSelect -> delegates to ParallelSelectOperation
> > .sequentialSelect -> delegates to SelectOperation
> > . select -> delegates to ParallelSelectOperation if it is not being
> > invoked from a parallel operation – in simpler terms, if
> > Thread.currentThread().getName().equals(“main”) – otherwise
> > delegates to SelectOperation.
> >
> >
> >
> > Therefore the default automatically chooses the appropriate one.
> > However the user can also explicitly specify which implementation
> > they want if they desire. Currently I have a prototype with
> > additional tests (specifically
> > org.eclipse.epsilon.eol.engine.test.acceptance.firstOrder.nested.Au
> > toParallelOperationTests) in the parallel-epsilon branch.
> >
> >
> >
> > Please let me know if there are any suggestions. If there are no
> > objections I propose to merge this into the main branch.
> >
> >
> >
> > Thanks,
> >
> > Sina
> >
> >
> >
> > [1]
> > https://git.eclipse.org/c/epsilon/org.eclipse.epsilon.git/tree/plugins/org.eclipse.epsilon.eol.engine/src/org/eclipse/epsilon/eol/execute/operations/EolOperationFactory.java?h=parallel-epsilon
> >
> >
> >
> >
> >
> > _______________________________________________
> > epsilon-dev mailing list
> > epsilon-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/epsilon-dev
>
>
