diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki index 33c15bad..8182b73f 100644 --- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki +++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki @@ -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. -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 Current 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 Current 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. diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki index b2f3601c..1c3ee572 100644 --- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki +++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki @@ -59,6 +59,7 @@ Also, if you use an anchored declaration such as: and the type of my_query is separate, you should make sure you are using revision 86657 or later. + ==Agents targeted to objects of separate types== In version 6.8, agents targeted on separate objects are not supported.