| Re: [epsilon-dev] Automatic substitution for parallel operations |
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.isTopLevelThread(). I will try to write a plugged-in test to verify that this is a viable approach. 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. P.S.: I’m still not receiving mails from the mailing list, hence the copy-paste below. Thanks, Sina -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi Sina,Auto-detecting when parallel operations can be safely used would bevery useful indeed! I'm only wondering whetherThread.currentThread().getName().equals(âmainâ) is a reliable way ofdetermining whether we're in a "top-level" thread. Does this hold whenan Epsilon program is ran through the Eclipse-based development toolsor e.g. through Tomcat? [1]Cheers,Dimitris[1] https://www.eclipse.org/epsilon/doc/articles/egl-server-side/From: Sina Madani 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:
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.AutoParallelOperationTests) 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 |