Difference between revisions of "Uno/Effort/Binary/Extend Threading-Model"
(→Tasks: updated task states.) |
m (Sorted tasks.) |
||
| Line 1: | Line 1: | ||
| − | Type: [[Uno/Term/Effort|effort]] Status: in progress | + | Type: [[Uno/Term/Effort|effort]] Status: in progress Owner: [[KR|Kay Ramme]], [mailto:Kai.Sommerfeld@sun.com] |
'''The mission of this effort is, to extend the [[Uno]] threading-model, to provide a way to design an applications [[Uno/Term/Threading-Architecture|threading-architecture]] independent of the implementations.''' This can be described as [[Uno/Term/Transparent Concurrency|'''transparent-concurrency''']] wrt the implementations. | '''The mission of this effort is, to extend the [[Uno]] threading-model, to provide a way to design an applications [[Uno/Term/Threading-Architecture|threading-architecture]] independent of the implementations.''' This can be described as [[Uno/Term/Transparent Concurrency|'''transparent-concurrency''']] wrt the implementations. | ||
| Line 7: | Line 7: | ||
==Solution== | ==Solution== | ||
| − | The extended [[Uno]] threading-model is going to | + | The extended [[Uno]] threading-model is basically going to introduce the notion of an apartment into the [[Uno]] world. An apartment in [[Uno/Term|Uno terms]] is a [[Uno/Spec/Purpose Environment|purpose environment]]. Such an environment can be seen as a dedicated part of a process, giving space for objects of the same [[Uno/Term/Object Binary Interface|Object Binary Interface (OBI)]] and the same purpose. An environment can only be entered and left via defined doors, being proxy objects representing objects outside respectively inside the environment. |
[[Image:UNO_Envs.jpg]] | [[Image:UNO_Envs.jpg]] | ||
| Line 13: | Line 13: | ||
All calls from one [[Uno/Spec/Environment|Uno Environment]] to another are intercepted, references to local objects are replaced with proxies to these local objects, this operation is called "mapping" in Uno terms. Actually, an object gets "mapped" from one [[Uno/Spec/Environment|Uno Environment]] to another. Proxies already representing to be mapped objects of another [[Uno/Spec/Environment|Uno Environment]] become reused during the "mapping" operation, ensuring that an object can only be "mapped" once. | All calls from one [[Uno/Spec/Environment|Uno Environment]] to another are intercepted, references to local objects are replaced with proxies to these local objects, this operation is called "mapping" in Uno terms. Actually, an object gets "mapped" from one [[Uno/Spec/Environment|Uno Environment]] to another. Proxies already representing to be mapped objects of another [[Uno/Spec/Environment|Uno Environment]] become reused during the "mapping" operation, ensuring that an object can only be "mapped" once. | ||
| − | [[Uno/Spec/Purpose Environment|Purpose environments]] may be dedicated to MutExes or threads. In the sense, that a MutEx becomes acquired or a thread gets switched to before a call enters an environment. | + | [[Uno/Spec/Purpose Environment|Purpose environments]] may be dedicated to MutExes or [[Wikipedia:Thread_%28computer_science%29|threads]]. In the sense, that a MutEx becomes acquired or a [[Wikipedia:Thread_%28computer_science%29|thread]] gets switched to before a call enters an environment. |
==Time Frame== | ==Time Frame== | ||
| − | Current understanding of the topic lets us think, that the first changes of OOo / [[Uno]] on behalf of the extend threading-model are going to be integrated into one of the next updates, probably late in 2006. The plan is, to implement the whole stack into the UTF2 CWS to ensure that everything works as expected, and to split the implementation into 'integration chunks', to be integrated with different CWS, to reduce the risk of breaking anything. | + | Current understanding of the topic lets us think, that the first changes of OOo / [[Uno]] on behalf of the extend threading-model are going to be integrated into one of the next updates, probably late in 2006. The plan is, to implement the whole stack into the {{Uno/CWS|SRC680|UTF2}} [[CWS]] to ensure that everything works as expected, and to split the implementation into 'integration chunks', to be integrated with different [[CWS]], to reduce the risk of breaking anything. |
==Tasks== | ==Tasks== | ||
| Line 22: | Line 22: | ||
|- style="background:#efefef;" | |- style="background:#efefef;" | ||
| Area || Title || State || [[CWS]] | | Area || Title || State || [[CWS]] | ||
| + | |- | ||
| + | | [[Uno/Cpp|C++ Uno]] || | ||
| + | Misc Improvements | ||
| + | * uno::Environment Convenience Constructors | ||
| + | * uno::Mapping Convenience Constructors | ||
| + | || 100% || {{Uno/CWS|SRC680|krmisc}} | ||
|- | |- | ||
| [[Uno/Binary|Binary Uno]] || | | [[Uno/Binary|Binary Uno]] || | ||
Preparation | Preparation | ||
| − | * enable identity mapping: getting a Uno Mapping from and to the same environment - currently the runtime does return NULL, so every client has to check for it, | + | * enable identity mapping: getting a Uno Mapping from and to the same environment |
| + | - currently the runtime does return NULL, so every client has to check for it, | ||
* cleanup the dll component loader | * cleanup the dll component loader | ||
** to use the identity mapping, and | ** to use the identity mapping, and | ||
| Line 31: | Line 38: | ||
|| 100% || {{Uno/CWS|SRC680|bunoidmap}} | || 100% || {{Uno/CWS|SRC680|bunoidmap}} | ||
|- | |- | ||
| − | | [[Uno/Binary|Binary Uno]] || | + | | [[Uno/Binary|Binary Uno]] || Extend [[Uno/Binary/Impl/Threading-Model|Threading-Model]] || 90% || {{Uno/CWS|SRC680|bunoexttm}} |
|- | |- | ||
| − | | [[Uno/ | + | | [[Uno/Cpp|C++ Uno]] || Extend [[Uno/Cpp/Impl/Threading-Model|Threading-Model]] || 75% || {{Uno/CWS|SRC680|bunoexttm}} |
|- | |- | ||
| [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Implement Environment Stack Support]] || 50% || {{Uno/CWS|SRC680|utf2}} | | [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Implement Environment Stack Support]] || 50% || {{Uno/CWS|SRC680|utf2}} | ||
|- | |- | ||
| [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Purpose Bridge Tester|Purpose Bridge Tester]] || 80% || {{Uno/CWS|SRC680|utf2}} | | [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Purpose Bridge Tester|Purpose Bridge Tester]] || 80% || {{Uno/CWS|SRC680|utf2}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
|- | |- | ||
| [[Uno/Cpp|C++ Uno]] || [[Uno/Cpp/Impl/Purpose Bridge Implementation Helper|Purpose Bridge Implementation Helper]] || 100% || {{Uno/CWS|SRC680|utf2}} | | [[Uno/Cpp|C++ Uno]] || [[Uno/Cpp/Impl/Purpose Bridge Implementation Helper|Purpose Bridge Implementation Helper]] || 100% || {{Uno/CWS|SRC680|utf2}} | ||
| + | |- | ||
| + | | [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Adapt Threading-Architecture|Adapt Threading Architecture]] || 90% || {{Uno/CWS|SRC680|utf2}} | ||
|} | |} | ||
Revision as of 09:49, 24 November 2006
Type: effort Status: in progress Owner: Kay Ramme, [1]
The mission of this effort is, to extend the Uno threading-model, to provide a way to design an applications threading-architecture independent of the implementations. This can be described as transparent-concurrency wrt the implementations.
Contents
Problem
Not everything should be required to be implemented thread-safe. E.g. see comments from John Ousterhout regarding multi-threading. Encapsulation of thread-affinity should be easy.
Solution
The extended Uno threading-model is basically 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 Object Binary Interface (OBI) and the same purpose. An environment can only be entered and left via defined doors, being proxy objects representing objects outside respectively inside the environment.
All calls from one Uno Environment to another are intercepted, references to local objects are replaced with proxies to these local objects, this operation is called "mapping" in Uno terms. Actually, an object gets "mapped" from one Uno Environment to another. Proxies already representing to be mapped objects of another Uno 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 to before a call enters an environment.
Time Frame
Current understanding of the topic lets us think, that the first changes of OOo / Uno on behalf of the extend threading-model are going to be integrated into one of the next updates, probably late in 2006. The plan is, to implement the whole stack into the UTF2 CWS to ensure that everything works as expected, and to split the implementation into 'integration chunks', to be integrated with different CWS, to reduce the risk of breaking anything.
Tasks
| Area | Title | State | CWS |
| C++ Uno |
Misc Improvements
|
100% | krmisc |
| Binary Uno |
Preparation
- currently the runtime does return NULL, so every client has to check for it,
|
100% | bunoidmap |
| Binary Uno | Extend Threading-Model | 90% | bunoexttm |
| C++ Uno | Extend Threading-Model | 75% | bunoexttm |
| Binary Uno | Uno/Effort/Binary/Implement Environment Stack Support | 50% | utf2 |
| Binary Uno | Purpose Bridge Tester | 80% | utf2 |
| C++ Uno | Purpose Bridge Implementation Helper | 100% | utf2 |
| Binary Uno | Adapt Threading Architecture | 90% | utf2 |
