[ciao-users] EXT :Re: Multithreaded dance_locality_manager method call dispatcher?

[Johnny Willemsen]

Hi,

The DAnCE locality has a single threaded and re-entrent default
execution model. With some work it could be made multi threaded but that
will require all code to be thread-safe.

We as Remedy IT have created AXCIOMA as a successor of CIAO/DAnCE. We
have recently finished a first prototype of a new addon, the AXCIOMA
Execution Framework (ExF). With ExF we can extend AXCIOMA with different
execution models like single-threaded/non-reentrent, but also various
multi threading models which could be combined with different
queue/dispatch models. We are working on a new presentation to show the
concepts and power of ExF, we should have that online in some weeks.
When you want to know more about AXCIOMA and what it could do, see
http://www.remedy.nl/en/axcioma or contact me directly.

Best regards,

Johnny Willemsen
CTO Remedy IT

On 05/13/2015 04:26 PM, Hayman, Mark (ES) wrote:
> Kai,
> 
> Will's suggestion to use AMI4CCM will work well in term of eliminating unnecessary container work thread lockup due to synchronous/blocking calls from component client ports.
> 
> Perhaps you are instead worried about long-running operation implementations on servant/server side ports rather than client ports, and have 2 or more on the same component (or on multiple components mapped to the same DAnCE LM component server process) that will execute for an extended period before returning to the event queue, thus preventing other events from being dispatched & processed by that same container?  If so, my suggestion would be to allocate those server ports/operations to two different components instead, if they're on just one, and deploy the two+ components each to their own DAnCE LM component server process.  That's the easy approach to CIAO+DAnCE multi-threading.  Specifically, use multiple LM processes instead of multiple threads in the same process.  It has the nice added decoupling benefit of eliminating all the accidental complexities involved with having to write multi-threaded code and deal with concurrent access issues.
> 	
> -Mark
> 
> -----Original Message-----
> From: ciao-users [mailto:ciao-users-bounces at list.isis.vanderbilt.edu] On Behalf Of William Otte
> Sent: Wednesday, May 13, 2015 9:59 AM
> To: CIAO Users Mailing List
> Subject: EXT :Re: [ciao-users] Multithreaded dance_locality_manager method call dispatcher?
> 
> Hi Kai -
> 
> Thanks for using the PRF.  I discarded your message to tao-users, in order to keep this discussion in the appropriate forum, but cleared your moderate flag for that list as well.
> 
> On 13 May 2015, at 8:37, kai-uwe.schieser at diehl.com wrote:
> 
>> CIAO VERSION: 1.2.3
>> TAO VERSION : 2.2.3
>> ACE VERSION : 6.2.3
>>
>> HOST MACHINE and OPERATING SYSTEM:
>> Windows 7
>>
>> $ACE_ROOT/ace/config-win32.h
>>
>> THE PROBLEM AFFECTS: Execution
>>
>> TAO/CIAO are affected.
>>
>> SYNOPSIS:
>> Multithreaded dance_locality_manager method call dispatcher?
>> Interface calls to components in an single dance_locality_manager are 
>> dispatched single threaded.
>>
>> DESCRIPTION:
>>
>> Hi there!
>> I am using CIAO as CCM implementation and have the following problem:
>> So far I deploy my components on a local machine (localhost) and they 
>> are running in a single dance_locality_manager process. It seems that 
>> all incoming interface calls (and also intercomponent calls) are 
>> dispatched by a single thread in the dance_locality_manager. This is a 
>> problem because some interface calls need long processing time. I 
>> would like to call more interface methods in parallel. Is there a TAO 
>> ORB option to enable some kind of multithreaded dispatching?
>> Thanks in advance, Kai.
> 
> That is certainly possible using a svc.conf file (I'll refer you to the TAO documentation for the details on that, but can dig it up if you are still interested).  It is, however, not currently a currently tested (and thus not supported) configuration, and I don't know if there will be unintended side effects.
> 
> A better solution to your problem is to explicitly design for asynchronous behavior for such long-running method calls using AMI4CCM (https://github.com/DOCGroup/ATCD/tree/master/CIAO/connectors/ami4ccm).
> 
> hth,
> /-Will
> _______________________________________________
> ciao-users mailing list
> ciao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ciao-users
> _______________________________________________
> ciao-users mailing list
> ciao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ciao-users
> 
>