Uno/Spec/Threading-Model

author: Kr
version: 5796
state: draft
created: 12/12/2006
changed: 12/12/2006
type: specification

UNO Threading Model

Feature

Abstract UNO Threading Model

UNO Runtimes can provide support for simplifying implementing thread safe or thread affine code. Code can be differentiated into

* client code

* component / object code

The UNO Threading Model allows code to leverage external locking, respectively to leverage thread specificy.

For that to work, code has to decide to use one of three threading models:

* thread safe

* thread unsafe

* thread affine

The Free Threading Model

# code needs to take care of any threading issues, e.g. as locking critical sections etc.

This model should be leveraged for code doing blocking system calls, while providing an API for interruption. This model may also be used if a high degree of concurrency is needed, while one wants to eliminate any kind of apartment overhead.

The Thread-Unsafe Model

# code does not need to take care of any locking issues

# code running in the Unsafe Thread Model is guaranteed to only be invoked once paralell per runtime.

# code needs to take care of any thread affinity, means that code may be called by different threads alternately.

This should become the standard model of implementation. Ensuring all code to be in this Model and utilizing only one thread should give optimal performance without any threading overhead.

The Affine Thread Model

* Is the as in the Unsafe Thread Model, while deleting -3-

* Code in the Affine Thread Model can rely on being called by the same thread always.

The Affine Thread Model is e.g. very usable for programming Windows thread affine APIs, e.g. OLE or WIN32.

The programming counterpart for a threading model is the so called apartment.

The different Threading Models are to be implemented via UNO environments being backed by apartments. A UNO Threading Model supporting UNO Runtime needs to provide:

* threading model specific environment access (e.g. uno:mutex or java:thread)

* an API for accessing the current apartment (the threading model)

* an API for accessing the default apartments (mutex, thread, free)

The apartments need to provide APIs for:

* getting the name of an apartment

Apartments Access Characteristics

The different threading model specific apartments have different access characteristics, derived from the backing apartments:

Free

* Has no (threading) restrictions.

Mutex Apartment

* Can only be entered by one thread at a time.

* Keepy being entered, even if the thread calls into another apartment.

* Can be re-entered by a thread.

Thread Apartment

* Inherits the Mutex apartment attributes.

* Has an associated thread.

* All encapsulated objects only become called by the associated thread.

* Blocks the entering thread and switches to the associated thread, passes along all parameters

* Relieves the entering thread when the associated thread has executed the desired method. Passes back all results.

* Switches back to the entering thread, in case an outside object should be called, passes along all parameters.

* Switches back to the associated thread, when comming back from an outside call, passes back all results.