Difference between revisions of "Uno/Article/Multi-Thread Programming"
(Arcticle about UNO Multi Threading Programming.) |
(Extended.) |
||
| Line 1: | Line 1: | ||
== Multi Threading Programming == | == Multi Threading Programming == | ||
| − | UNO is inherently multi threaded. Every instance of a UNO | + | 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. |
| − | '''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 | + | Every UNO reference points to an object with particular characteristics. Among implemeting the concrete interface type, the object may belong to a particular purpose environment. The UNO Threading Framework introduces the Thread Affine and Thread Unsafe Purpose Environments. Objects not belonging to one of these two purpose environments are Thread Safe. Depending on what should be implemented, either 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 <code>getCurrentEnvironment</code> 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 === | === Components === | ||
| − | If you are going to implement a UNO component, you need decide on the threading architecture of | + | If you are going to implement a UNO component, you need to decide on the threading architecture of it. You basically have three choices: |
* Thread Unsafe | * Thread Unsafe | ||
* Thread Safe | * Thread Safe | ||
* Thread Affine | * Thread Affine | ||
| − | + | '''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 system. | ||
| + | |||
| + | ==== 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 should or must allow the concurrent execution of some methods, or | ||
* your component wants to avoid the overhead associated with leaving synchronization to the system. | * your component wants to avoid the overhead associated with leaving synchronization to the system. | ||
| − | One case, where your | + | 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 com.sun.star.impl.Acceptor implementation. |
The overhead for automatic synchronization only affects inter-environment calls. In most cases, the threading architecture should be designed in a way, that closely connected objects happen to exist in the same environment. Basically ensuring a low call frequency, converting the advantage of self synchronized methods to the reverse. | The overhead for automatic synchronization only affects inter-environment calls. In most cases, the threading architecture should be designed in a way, that closely connected objects happen to exist in the same environment. Basically ensuring a low call frequency, converting the advantage of self synchronized methods to the reverse. | ||
| − | '''Note:''' | + | '''Note:''' Scaling may be achieved by the introduction of Named Environments, basically allowing any number of Thread Unsafe Purpose Environments to exist simultanesously and to be entered by multi threads concurrently. |
| + | |||
| + | ==== Thread Affine ==== | ||
| + | Thread Affine components are rare. In OOo they are needed to encapsulate the Win32 thread affinity. | ||
=== Libraries === | === Libraries === | ||
Libraries providing functions dealing with UNO references may be implemented as | Libraries providing functions dealing with UNO references may be implemented as | ||
* free, meaning that the library can deal with any kind of reference, or as | * free, meaning that the library can deal with any kind of reference, or as | ||
| − | * specialized, meaning that the library can deal with one particular type of references only. | + | * specialized, meaning that the library can deal with one particular purpose type of references only. |
| + | Free and specialized functions can 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 <code>EnvAwareReference</code> 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 can than provide matching objects, 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 code. Depending on the supported 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. | ||
| − | |||
[[Category:Uno:Article]] | [[Category:Uno:Article]] | ||
Revision as of 15:55, 31 May 2006
Contents
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 implemeting the concrete interface type, the object may belong to a particular purpose environment. The UNO Threading Framework introduces the Thread Affine and Thread Unsafe Purpose Environments. Objects not belonging to one of these two purpose environments are Thread Safe. Depending on what should be implemented, either 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 of it. You basically have three choices:
- Thread Unsafe
- Thread Safe
- Thread Affine
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 system.
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 system.
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 com.sun.star.impl.Acceptor implementation.
The overhead for automatic synchronization only affects inter-environment calls. In most cases, the threading architecture should be designed in a way, that closely connected objects happen to exist in the same environment. Basically ensuring a low call frequency, converting the advantage of self synchronized methods to the reverse.
Note: Scaling may be achieved by the introduction of Named Environments, basically allowing any number of Thread Unsafe Purpose Environments to exist simultanesously and to be entered by multi 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 references may be implemented as
- free, meaning that the library can deal with any kind of reference, or as
- specialized, meaning that the library can deal with one particular purpose type of references only.
Free and specialized functions can 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 can than provide matching objects, 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 code. Depending on the supported 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.
