Difference between revisions of "Uno/Effort/Binary/Extend Threading-Model"

Revision as of 09:20, 21 April 2006

Creating the UNO Threading Framework

[1], [2]

Status: in progress

The goal of the UNO threading framrwork is, to provide a way to design an applications threading architecture independent of the implementation. This can be described as Transparent Concurrency, in respect to the implementations.

The UNO Threading Framework basically is going to introduce the notion of an apartment into the UNO world. An apartment in UNO terms is a purpose environment. Such an environment can be seen as a dedicated part of a process, giving space for objects of the same ABI and the same purpose. An environment can only be entered and left via defined doors, being proxy objects representing objects outside respectively inside the apartment.

All calls from one environment to another are intercepted, references to local objects get replaced with proxies to these local objects, this operation is called "mapping" in UNO terms. An object gets "mapped" from one environment to another. Proxies already representing to be mapped objects of another environment become reused during the "mapping" operation, ensuring that an object can only be "mapped" once.

Purpose environments may be dedicated to MutExes or threads. In the sense, that a MutEx becomes acquired or a thread gets switched before a call enters an environment.

The following specifications and features give an overview over the UNO Threading Framework. The specifications roughly depend on each other in the order listed. For example, the Threading Models specification depends on the Implementation Environments, all pieces basically creating a stack.

Dependencies

Current understanding of the topic lets us think, that the changes of OOo / UNO on behalf of the Threading Framework are going to be integrated into one of the next updates, probably early in 2006.