On 3/25/2014 7:46 PM, Richard Eckart de Castilho wrote:
> Thanks for the explanation ;) However, I meant actual comments in the code.
Ok, I agree. I've been added a lot of that info as comments - I'll attempt to
be more diligent!
> 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.
I agree, and feel this might be a fairly long journey - done in some incremental
way...
>
> Btw. embedding is one of the main use-cases of uimaFIT as well. It makes
> embedding very comfortable ;)
:-) -Marshall
> -- 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
>>>
>
>
