Architecture/Goals for OOo Threading-Model&-Architecture

From Apache OpenOffice Wiki
< Architecture
Revision as of 13:10, 21 April 2006 by Kr (talk | contribs) (moved from udk.openoffice.org)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Type: proposal Status: draft Version: 0.3

Author: Kai Sommerfeld, Kay Ramme

Goals for the OOo Threading Model & Architecture

As to be read in the OOo multi threading status document, several expectations regarding the various multi threading issues exist. These expectations have been assigned 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 multi threading model and the multi threading architecture.

The Threading Model

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 threading status document, 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 - 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)):
    • Thread Affine
    • Thread Safe
    • Thread Unsafe

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

The Threading Architecture

The Threading Architecture defines, where threads are used in OOo, respectively which components are following which threading approach.

The following expectations from the threading status document 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 focusses 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.
Personal tools