Difference between revisions of "Uno/Effort/Binary/Extend Threading-Model"
m |
m (→Tasks: Replaced Uno/Effort/Binary/Threading Model.) |
||
| Line 34: | Line 34: | ||
| Area || Effort || State | | Area || Effort || State | ||
|- | |- | ||
| − | | [[Uno/Binary|Binary Uno]] || [[Uno | + | | [[Uno/Binary|Binary Uno]] || [[Uno/Binary/Impl/Threading Model|Implement Threading Model]] || 90%, UTF2 |
|- | |- | ||
| [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Debug Bridge | Debugging Bridge]] || 90% | | [[Uno/Binary|Binary Uno]] || [[Uno/Effort/Binary/Debug Bridge | Debugging Bridge]] || 90% | ||
Revision as of 14:46, 28 June 2006
Creating the UNO Threading Framework
Status: in progress
Mission
The mission 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 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 before a call enters an environment.
Background
Code may actually vary in its capabilities regarding 'Transparent Concurrency'. Code may be differentiated into Code using
- global variables, or
- thread local variables, or
- parameters only, or
- value parameters only, or
- doing internal protection of critical sections, or
- not doing internal protection.
Such categorizations help to decide, what one can do with a particular implemention. Also the codes threading type is a compile time information and may therefor be used during compilation, so that the compiler may give errors when mixing thread safe and thread unsafe code in a multi thread scenario.
Time Frame
Current understanding of the topic lets us think, that the first changes of OOo / UNO on behalf of the Threading Framework are going to be integrated into one of the next updates, probably mid 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 Effort State Binary Uno Implement Threading Model 90%, UTF2 Binary Uno Debugging Bridge 90% Binary Uno New UNO Threading Architecture open C++ Uno Threading Model in progress - 75% Java Uno the Threading Model 0% CLI Uno Uno Threading Model 0% Remote Uno Uno Threading Model 0% C++ Uno Misc Improvements UTF2 C++ Uno Purpose Bridge Implementation Helper UTF2 Binary Uno Jni-Uno Bridge - Purpose Environment Support 0% Binary Uno ABI Bridge Tester 0% Binary Uno Purpose Bridge Tester 0% Java Uno Java-Urp Bridge - Purpose Environment Support 0% Binary Uno Purpose Environment Support for the Component Loader 0% Binary Uno Uno-Urp Bridge - Purpose Environment Support 0%
