View source for Architecture/Goals for OOo Threading-Model&-Architecture

From Apache OpenOffice Wiki

← Architecture/Goals for OOo Threading-Model&-Architecture

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

---

You can view and copy the source of this page.

Type: Proposal Status: Final Authors: Kai Sommerfeld, [[KR|Kay Ramme]] As to be read in the [[Analysis/Multi-Threading|OOo multi-threading analysis]], several expectations regarding the various multi-threading issues exist. These expectations may be differentiated to either refer to the [[Uno/Term/Threading-Model|threading-model]] or to the [[Uno/Term/Threading-Architecture|threading-architecture]]. Below these are listed accordingly and conclusions are drawn. These conclusions should give an orthogonal set of rules, helping to define the [[Uno/Term/Threading-Model|threading-model]] and the [[Uno/Term/Threading-Architecture|multi-threading-architecture]]. ==[[Uno/Term/Threading-Architecture|Threading-Architecture]] Relevant== A [[Uno/Term/Threading-Architecture|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 [[Analysis/Multi-Threading|threading analysis]] are [[Uno/Term/Threading-Architecture|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 - [[Uno/Term/Thread Aware|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 - [[Uno/Term/Thread Aware|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 [[Uno/Term/Threading-Model|threading-model]] neutral (can be used for any kind of COM / OLE programming (STA / MTA)). These expectations can be summarized as follows: # There is one well defined [[Uno/Term/Threading-Architecture|threading-architecture]] (addressing (J),(K)). # OOo has to scale in a defined way with multiple client threads, e.g. on a document granularity (addressing (A),(B),(C)). # Operations are interruptible (addressing (C)). # Long lasting operations are delegated into threads (addressing (C)). # All [[Uno/Term/Thread Aware|thread-aware]] code is well tested (addressing (E)). # There is no unnecessary [[Uno/Term/Thread Aware|thread-aware]] code (addressing (D),(F),(G),(H),(I)). # 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). ==[[Uno/Term/Threading-Model|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 [[Analysis/Multi-Threading|threading status analysis]], listing the expectations, which are threading-model relevant: * A - There is a well specified [[Uno/Term/Threading-Model|threading-model]]. * B - The OOo UNO API implementations can be used by multiple threads and clients simultaneously. * C - There is a specified [[Uno/Term/Threading-Architecture|threading-architecture]] ensuring, that the OOo [[Uno]] API is [[Uno/Term/Thread Safe|thread-safe]]. * D - It can be decided case by case, what the [[Uno/Term/Threading-Architecture|threading-architecture]] of a particular component is. * E - A [[Uno/Term/Thread Safe|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 [[Uno/Term/Thread Affine|thread-affine]] in any kind (depends on [[Uno/Term/Threading-Architecture|threading-architecture]]). * J - VCL is [[Uno/Term/Thread Transparent|thread-transparent]] (depends on [[Uno/Term/Threading-Architecture|threading-architecture]]). * K - VCL is threading-model neutral. * L - Systems can be initialized by any thread (depends on [[Uno/Term/Threading-Architecture|threading-architecture]]). * M - OOo can be used by multiple ISV (integration) solutions simultaneously. These expectations can be summarized as follows: # OOo has to have one [[Uno/Term/Threading-Model|threading-model]] only (addressing (A),(G)). # An API has to be [[Uno/Term/Thread Transparent|thread-transparent]] (addressing (H),(I),(J),(K),(L),(E)). # An [[Uno]] API has to be [[Uno/Term/Thread Safe|thread-safe]] (addressing (B),(C),(M)). # Code has to be implemented following one of three threading approaches (addressing (D),(F)): #* [[Uno/Term/Thread Affine|Thread-Affine]] #* [[Uno/Term/Thread Safe|Thread-Safe]] #* [[Uno/Term/Thread Unsafe|Thread Unsafe]] These rules are going to be the basis for the [[Uno/Spec/Threading-Model|OOo threading-model]]. [[Category:Proposal]]

Return to Architecture/Goals for OOo Threading-Model&-Architecture.