mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 23:32:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2011-06-10T01:28:43.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@922 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2011-06-10 18:52:27 +00:00
parent d7777c11a4
commit 4d23dce4bf
2 changed files with 8 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki
View File

@@ -64,7 +64,7 @@ In traditional, sequential Eiffel, although we realize that there is some proces
The term ''processor'' (or, interchangeably, ''handler'') is vital to SCOOP and thought of in a slightly different way than in traditional Eiffel, i. e., not just as a hardware processor. In a concurrent system, there may be any number of ''processors''. Here the term is used in a more abstract sense than before. In SCOOP we think of a processor as any autonomous thread of control capable of applying features to objects. At the level of the SCOOP model, processors are not restricted to a particular type of hardware or software. So, if you were writing software for a hardware implementation with multiple processors, those real processors might correspond to the ''processors'' of SCOOP. But if you were writing a system using multiple process threads, then those threads might correspond to SCOOP ''processors''.
{{note|In the initial SCOOP implementation in EiffelStudio version 6.8, process threads are the only supported concurrency mechanism. }}
{{note|In the initial SCOOP implementation in EiffelStudio version 6.8, multiple process threads are the only supported concurrency mechanism. So, each SCOOP processor is implemented as a separate thread of execution in a single process. }}
Multiple processors in SCOOP come into play when feature calls on a particular object may actually be applied by a different processor than the one on which the feature call was issued. Of course, this is the important distinction between feature call and feature application that was mentioned above. In SCOOP, the processor which does the feature application may be different from the one that does the feature call. So you can think of feature call as being the ''logging'' or ''queuing'' of a request to have a feature applied.

8
documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
View File

@@ -17,7 +17,13 @@ The differences between the EiffelStudio implementation of SCOOP and current and
==Supported concurrency mechanisms==
Although the SCOOP model can support virtually any underlying concurrency mechanism, the initial SCOOP implementation supports only process threads as SCOOP [[Concurrent Eiffel with SCOOP#Processors|processors]].
Although the SCOOP model can support virtually any underlying concurrency mechanism, the initial SCOOP implementation in EiffelStudio version 6.8 supports only one executable, using multiple process threads as SCOOP [[Concurrent Eiffel with SCOOP#Processors|processors]].
==SCOOP processor termination==
In version 6.8, a SCOOP processor, once created, does not terminate until the entire SCOOP application that created it terminates. This occurs when all processors in the application become idle, that is, when there are no more calls logged on any processor and no calls are in the process of being applied.
In a future version, garbage collection will determine when a particular SCOOP processor may terminate.
==Separate anchored types==