Re: [epsilon-dev] Automatic substitution for parallel operations

[Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>]

Hi Sina,

Sure - please feel free to go ahead and merge these changes if all tests pass.

Cheers,
Dimitris

On Mon, 15 Apr 2019 at 18:12, <sm1748@xxxxxxxxxx> wrote:
>
> 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
> >
> >
>


-- 
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos

EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm