[20] MULTI-THREADED ARCHITECTURES
(Part of the CORBA FAQ, Copyright © 1996-97)

[20.1] CAN CORBA APPLICATIONS BE MULTI-THREADED?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

The CORBA specification does not currently address multi-threaded architectures. Provided that the CORBA product is thread safe, threaded CORBA applications can be developed. CORBA clients and servers can both be multi-threaded. Daemon processes provided with CORBA products may be implemented as multi-threaded servers by the CORBA vendor. Different multi-threaded models or multi-threaded architectures may be supported by a particular CORBA product. A particular ORB may provide frameworks to simplify the development of multi-threaded CORBA applications.

[ Top | Bottom | Previous section | Next section ]

[20.2] WHY WOULD I DECIDE TO IMPLEMENT A CORBA CLIENT APPLICATION WITH MULTI-THREADING?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Client-side CORBA applications might require multi-threading to allow it to perform other tasks while it is waiting for a synchronous remote invocation to return. It might desire this functionality for several different reasons.

1. A client application might wish to leverage the static request/response style of invocation but achieve some degree of asynchronous communication. Perhaps the client wishes to perform several synchronous invocations within their own application threads. This would allow a client to obtain results from several remote servers more quickly. There are several reasons the use of multi-threading might be preferred over the use of DII. DII might be complicate application source code. Application polling associated with the deferred synchronous invocation might result in a performance bottleneck.
2. A client-side CORBA application might need to respond to events such as incoming invocations, connect requests, or GUI events (mouse clicks, etc.) CORBA products that support only blocking style remote invocations will be unable to process any of these events. This would mean that a client-side application would be unable to respond to GUI events for the duration of any remote CORBA invocations. This is not an issue for short duration invocations but becomes a problem for longer invocations or in failure or time-out situations. Performing remote invocations within dedicated threads can avoid this issue.

[ Top | Bottom | Previous section | Next section ]

[20.3] WHY WOULD I DECIDE TO IMPLEMENT A CORBA SERVER APPLICATION WITH MULTI-THREADING?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

CORBA server applications may be multi-threaded for serveral reasons.

1. A particular CORBA object may support an operation whose implementation performs some blocking routine. This may be a disk read or database query. Let us assume that the server application processes all CORBA events within a single main thread. This means that the server will be unable to respond to incoming connection requests or invocation requests while the blocking operation is in progress. Multi-threading can be used to avoid these sorts of situations. The server can be more accessible if multiple threads are allowed to process (an block during) incoming CORBA events.
2. A single multi-threaded server process supporting many (>25) clients is much more efficient that many (>25) single-threaded server processes each supporting its own client. Running a single application with multiple threads requires less machine resources than running multiple applications. This advantage can be seen even if the operation invocations are of short duration and non-blocking.

[ Top | Bottom | Previous section | Next section ]

[20.4] ARE THERE DIFFERENT THREADING MODELS THAT CAN BE USED WITHIN CORBA SERVERS?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

There are several different common architectures that can be used within multi-threaded CORBA servers. A server process needs the ability to process CORBA messages. These messages are processed by exactly one thread. Messages may be targeted at the server or at some object within the server. The CORBA specification does not specifically address threading capabilities within CORBA compliant ORBs. An ORB vendor is free to support only single-threaded application or to support multi-threaded applications. If the ORB does support the development of multi-threaded applications, the ORB might only support a subset of the threaded models listed below. The actual ORB might only enable a developer to support one or more of the listed models. Significant threading might still need to be developed to achieve one of the models. For example, The ORB vendor might support a set of application hooks required for a developer to achieve a self-terminating thread per message.

1. A self-terminating thread for each incoming event: With this architecture, the CORBA server ensures that each incoming message is processed by its own thread. The CORBA server spawns a new thread when a message is de-queued it will respond to the message, and then reap itself. The main benefit of this architecture is that the server is capable of supporting an arbitrary number of concurrent requests. The main problem with this model is that each invocation requires a thread to be spawned and reaped. This is a relatively small amount of processing. An ORB product might require you to use certain internal ORB hooks (i.e. interceptors or filters) and allow you to implement this behavior with native OS threading. On the other hand, the ORB product might provide a built-in feature so no custom thread development needs to be done. The CORBA specification does not address this issue.
2. A pool of non-terminating threads for all incoming events: With this architecture, a server process would allocate a set of threads. Typically, a special thread will queue incoming requests and then the pool of threads will de-queue requests and respond to them. Objects must be heap allocated so that any thread in the pool can access the object. One cannot assume that all operations performed by a certain user or on a certain object are executed by a single thread. A ORB Product might require you to implement this behavior with native OS threading. On the other hand, the ORB product might provide a built-in feature so no low-level thread development needs to be done. The CORBA specification does not address this issue.
3. A thread (or thread pool) for all events associated with a given object: The thread(s) would be spawned when the object is created and reaped when the object is deleted. Once a message is processed, the thread is reaped and is no longer part of the application. The main benefit of this architecture is that the server is capable of supporting an arbitrary number of concurrent requests. The main problem with this model is that each invocation requires a thread to be spawned and reaped. This is a relatively small amount of processing.
4. A thread is associated with each client currently connected to the server. This requires that client connections can be monitored (typically at a network level, not an application level). This thread model serializes messages from the same client, while allowing multiple clients to use the server objects concurrently.

[ Top | Bottom | Previous section | Next section ]

[20.5] ARE THERE REASONS TO AVOID THE DEVELOPMENT OF MULTI-THREADED CORBA APPLICATIONS ?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Building multi-threaded applications requires an additional efforts in the area of design, development and testing. Issues like concurrency and synchronization become more critical. Difficult to find software bugs are unfortunately easy to introduce. A specific set of application requirements can often be met without resorting to the use of threaded clients or servers. This is not true with all applications. Some do require multi-threading to achieve their minimum level of concurrency, performance or scalability.

[ Top | Bottom | Previous section | Next section ]

 E-mail us