Architecture/Goals for OOo Threading-Model&-Architecture

From Apache OpenOffice Wiki
Jump to: navigation, search

Type: Proposal Status: Final Authors: Kai Sommerfeld, Kay Ramme

As to be read in the OOo multi-threading analysis, several expectations regarding the various multi-threading issues exist. These expectations may be differentiated to either refer to the threading-model or to the threading-architecture. Below these are listed accordingly and conclusions are drawn. These conclusions should give an orthogonal set of rules, helping to define the threading-model and the multi-threading-architecture.

Threading-Architecture Relevant

A threading-Architecture defines, where and how to use threads and thread related constructs. A threading-architecture may be expressed in terms of or may (implicitly) define a threading-model.

The following expectations from the threading analysis are threading-architecture relevant:

  • A - OOo scales with multiple clients e.g. calling on multiple documents.
  • B - OOo leverages multiple CPUs for executing simultaneous tasks, e.g. printing / loading / saving.
  • C - OOo is always alive and reacts immediately on available commands. At least the “abort” command needs to be available always.
  • D - Code does not workaround threading weaknesses.
  • E - Thread-aware code is well tested.
  • F - Locks are only used in scaling sensitive components.
  • G - Interlock counters are only used in scaling sensitive components.
  • H - Thread-aware code is only used in scaling sensitive parts.
  • I - Development most focuses on behavior / performance and less on not usable scalability.
  • J - There is a well specified threading architecture, documenting where threads are used and what does that mean for the programmer.
  • K - OSL threads are threading-model neutral (can be used for any kind of COM / OLE programming (STA / MTA)).

These expectations can be summarized as follows:

  1. There is one well defined threading-architecture (addressing (J),(K)).
  2. OOo has to scale in a defined way with multiple client threads, e.g. on a document granularity (addressing (A),(B),(C)).
  3. Operations are interruptible (addressing (C)).
  4. Long lasting operations are delegated into threads (addressing (C)).
  5. All thread-aware code is well tested (addressing (E)).
  6. There is no unnecessary thread-aware code (addressing (D),(F),(G),(H),(I)).
  7. These rules are going to be the basis for the OOo threading architecture.

These may include such attributes as fast (suiteable for GUI) and slow (not suiteable for GUI).

Threading-Model Relevant

The threading-model describes how threads are used throughout OOo. It defines what a user can expect from a particular API in respect to its threading behavior, helping the API client and the API implementation programmer.

The following is an extract from the threading status analysis, listing the expectations, which are threading-model relevant:

  • A - There is a well specified threading-model.
  • B - The OOo UNO API implementations can be used by multiple threads and clients simultaneously.
  • C - There is a specified threading-architecture ensuring, that the OOo Uno API is thread-safe.
  • D - It can be decided case by case, what the threading-architecture of a particular component is.
  • E - A thread-safe component can hold locks, while calling other objects.
  • F - MS Windows COM/OLE client code can be implemented easily as Uno components.
  • G - There is one well specified threading-model / -architecture.
  • H - VCL can be programmed in the same way on any platform.
  • I - No OOo API is thread-affine in any kind (depends on threading-architecture).
  • J - VCL is thread-transparent (depends on threading-architecture).
  • K - VCL is threading-model neutral.
  • L - Systems can be initialized by any thread (depends on threading-architecture).
  • M - OOo can be used by multiple ISV (integration) solutions simultaneously.

These expectations can be summarized as follows:

  1. OOo has to have one threading-model only (addressing (A),(G)).
  2. An API has to be thread-transparent (addressing (H),(I),(J),(K),(L),(E)).
  3. An Uno API has to be thread-safe (addressing (B),(C),(M)).
  4. Code has to be implemented following one of three threading approaches (addressing (D),(F)):

These rules are going to be the basis for the OOo threading-model.

Personal tools