Difference between revisions of "Uno/Article/Multi-Thread Programming"

Revision as of 15:24, 12 June 2006

Multi Threading Programming

UNO is inherently multi threaded. Every instance of a UNO component may be accessed by multiple threads concurrently. The UNO threading framework provides support to simplify multi thread programming.

Every UNO reference points to an object with particular characteristics. Among implementing the concrete interface type, the object may belong to a particular Purpose Environment. The UNO Threading Framework introduces the Thread Affine Purpose Environment and Thread Unsafe Purpose Environments. Objects not belonging to one of these two Purpose Environments are assumed to be Thread Safe. Depending on the type of the planned implementation, which either is a

• component, or a
• library, or an
• application,

care of the "purpose" characteristic of the involved objects needs to be taken.

Note: Unfortunately, no type safe specialized purpose references are yet available for any UNO language binding. So, this is planned. Currently, the only possible way to detect the purpose of a reference is at runtime, via the getCurrentEnvironment Runtime function.

Note: The UNO Runtime provides APIs for implementing any whished scenario. Including objects shared between different Purpose Environments or the instantiation of a Thread Safe component in a Thread Unsafe Environment. These mechanisms are in place to implement the Threading Framework itself, and to allow the programmer to gain full control, if needed.

Components

If you are going to implement a UNO component, you need to decide on the threading architecture. You basically have three choices:

• Thread Unsafe
• Thread Safe
• Thread Affine

C++ Example Components

• Uno/Example/Thread Unsafe Component
• Uno/Example/Thread Safe Component
• Uno/Example/Thread Affine Component
• Uno/Example/Free Component

Note: It is planned, to support the selection of an Implementation Environment (determining the components Purpose Environment) by a macro or an include. Some experiments have been done, so no final decisions have been made yet.

Thread Unsafe

Thread Unsafe is the choice for most cases. Actually leaving proper synchronization of method calls to the Runtime.

Thread Safe

There are only rare cases where you want to implement your component Thread Safe. Either

• your component should or must allow the concurrent execution of some methods, or
• your component wants to avoid the overhead associated with leaving synchronization to the Runtime.

One case, where your component must allow the concurrent execution of methods is, when you want to abort a running invocation. UNO currently does not offer a mechanism to do this generically, so that particular objects must provide dedicated methods for abortion. An example for this is the util/io/Acceptor implementation.

The overhead for automatic synchronization only affects inter-environment calls. The threading architecture of a particular application should be designed in a way, that closely connected objects happen to exist in the same Environment. Basically ensuring a low inter-environment call frequency, converting the potential advantage of self synchronized methods to the reverse.

Note: Scaling may be achieved by the introduction of Named Environments, actually allowing any number of Thread Unsafe Purpose Environments to exist simultanesously and to be entered by multiple threads concurrently.

Thread Affine

Thread Affine components are rare. In OOo they are needed to encapsulate the Win32 thread affinity.

Libraries

Libraries providing functions dealing with UNO objects may be implemented as

• free, meaning that the library can deal with any kind of objects, or as
• specialized, meaning that the library can deal with one particular purpose type of objects only.

Free and specialized functions may be mixed, depending on the libraries purpose, this may or may not be good style.

The API of "free" libraries should reflect the "freeness" by using the EnvAwareReference in its definition.

The cppuhelper library dynamically checks the current environment, and returns matching references, e.g. guaranteeing that Thread Safe and Thread Unsafe objects do not get mixed.

Applications

Application code implemented other than in the Thread Safe environment needs to explicitly enter the wished Purpose Environment before calling any UNO aware library. UNO aware libraries may than provide matching objects, dependent on the implementation, again ensuring that objects with different "purposes" do not get mixed.

Note: The planned introduction of Implementation Environments is going to be usable by the application programmer as well. It basically removes the necessity to explicitly enter a particular Purpose Environment.

Threads

You may create threads in your implementation. Depending on the select threading architecture, these threads may allowed to be visible from the outside or not. If your code is

• Thread Unsafe, than it must be Thread Transparent, if it is
• Thread Affine, than is must be Thread Transparent as well, if it is
• Thread Safe, it may create visible threads as needed.

Obviously, invisible threads can be used and created anytime anyway.