Thanks for the explanation ;) However, I meant actual comments in the code. Changes regarding multi-threading issues aren't the most obvious ones and per default, most code is developed only for single-threading. I think it would be good to explicitly mention thread-safety in the JavaDocs of those classes that are thread-safe, limit that to a select few classes, and go with the default assumption for all other classes. Design-wise, it may also be more maintainable in the long run to use immutable classes instead of mutable synchronized classes - at least in some instances.
Btw. embedding is one of the main use-cases of uimaFIT as well. It makes embedding very comfortable ;) -- Richard On 25.03.2014, at 20:33, Marshall Schor <[email protected]> wrote: > > On 3/25/2014 12:08 PM, Richard Eckart de Castilho wrote: >> On 25.03.2014, at 17:04, [email protected] wrote: >> >>> + protected synchronized void >>> resolveDelegateAnalysisEngineImports(Collection<String> >>> aEnclosingAggregateAeUrls, >>> ResourceManager aResourceManager, boolean aRecursive) throws >>> InvalidXMLException { >> Would it be unreasonable to ask for comments on methods or blocks that >> become synchronized explaining why they must be synchronized? > It's not unreasonable :-) > > I'm trying to include these. The main idea: UIMA has a set of APIs allowing > it > to be embedded in other systems; these are the so-called application APIs, > described here > http://uima.apache.org/d/uimaj-2.5.0/tutorials_and_users_guides.html#ugr.tug.application > > It's quite possible for an embedder to want to run a bunch of primitive > analysis > engines, in a multi-core environment, and to want to do their own "scale up" > of > these, using their own particular threading priorities, etc., for some > particular use case they have. > > We provide all the APIs to let embedders do this, but we (currently) don't do > a > very good job of allowing multiple threads to run parts of the pipeline setup, > in parallel. For multi-core machines, this can lead to a slowdown in setting > up > additional engines, because the setup could be going on (including running > that > engine's initialize method) on another core. > > This particular call (resolveDelegate...imports), fails if called on multiple > threads; these changes are to enable that. >> >> It sounds odd to me that descriptions would be shared across threads. > The use case for this is scale-out - you're taking one description of a > pipeline, but scaling it out to run on multiple cores. > > -Marshall >> >> Cheers, >> >> -- Richard >> >
