mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-08 15:52:26 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2011-07-06T15:36:43.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@932 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2011-07-10 14:45:10 +00:00
parent bde6580ce8
commit af2a90cd85
2 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -215,13 +215,13 @@ A feature call is '''asynchronous''' in the following case:
Let’s look a little closer at those cases determining synchronous calls. Let’s look a little closer at those cases determining synchronous calls.
Case 1 is the case of typical sequential Eiffel, where all calls are non-separate, and therefore synchronous. Of course, even in concurrent Eiffel with SCOOP, plenty of non-separate calls will occur, and these will be synchronous. Case S1 is the case of typical sequential Eiffel, where all calls are non-separate, and therefore synchronous. Of course, even in concurrent Eiffel with SCOOP, plenty of non-separate calls will occur, and these will be synchronous.
Case 2.1 says that if a separate call is a query it must be synchronous. This is because even though the feature application will probably occur on a different processor, the instructions following the query will likely depend up on the result of the query, so they must wait until the feature application completes. This situation is known as ''wait by necessity''. Case S2.1 says that if a separate call is a query it must be synchronous. This is because even though the feature application will probably occur on a different processor, the instructions following the query will likely depend up on the result of the query, so they must wait until the feature application completes. This situation is known as ''wait by necessity''.
Case 2.2 describes a situation in which a call provides at least one actual argument that is <code>Current</code> or is a separate formal argument of the call’s enclosing routine. In this case the client is calling a procedure and passing arguments which are ''controlled'' in the context of the calling routine. That is, the actual arguments are objects upon which the client processor has exclusive access in the enclosing routine. In order for the supplier processor to be able to apply the feature (presumably accessing the argument objects in the process), the client must pass its exclusive access to these objects on to the supplier. This is done through a mechanism called ''lock passing''. Because the client has passed its locks to the supplier processor, it cannot continue execution until the called feature has been applied by the supplier processor, and the supplier processor has relinquished the locks back to the client. Therefore, this type of call must be synchronous. Case S2.2 describes a situation in which a call provides at least one actual argument that is <code>Current</code> or is a separate formal argument of the call’s enclosing routine. In this case the client is calling a procedure and passing arguments which are ''controlled'' in the context of the calling routine. That is, the actual arguments are objects upon which the client processor has exclusive access in the enclosing routine. In order for the supplier processor to be able to apply the feature (presumably accessing the argument objects in the process), the client must pass its exclusive access to these objects on to the supplier. This is done through a mechanism called ''lock passing''. Because the client has passed its locks to the supplier processor, it cannot continue execution until the called feature has been applied by the supplier processor, and the supplier processor has relinquished the locks back to the client. Therefore, this type of call must be synchronous.
Now consider the only case, Case 1, determining asynchronous calls. Now consider the only case, Case A1, determining asynchronous calls.
Separate calls to commands are asynchronous (except as in case S2.2). This means that when a client executes an asynchronous feature call, it “logs” the need for its associated feature application. But then rather than waiting for the feature application to complete, the client routine continues execution of instructions beyond the asynchronous call. Separate calls to commands are asynchronous (except as in case S2.2). This means that when a client executes an asynchronous feature call, it “logs” the need for its associated feature application. But then rather than waiting for the feature application to complete, the client routine continues execution of instructions beyond the asynchronous call.

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

@@ -59,6 +59,7 @@ Also, if you use an anchored declaration such as:
and the type of <code>my_query</code> is <code>separate</code>, you should make sure you are using revision 86657 or later. and the type of <code>my_query</code> is <code>separate</code>, you should make sure you are using revision 86657 or later.
==Agents targeted to objects of separate types== ==Agents targeted to objects of separate types==
In version 6.8, agents targeted on separate objects are not supported. In version 6.8, agents targeted on separate objects are not supported.