Author:admin

Date:2011-04-14T08:28:02.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@872 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

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

@@ -196,24 +196,28 @@ After an asynchronous feature call, the execution of the client proceeds immedia
 First, every feature call is either a synchronous feature call or an asynchronous feature call. For a particular call, the following rules determine which it is:
 
 A feature call is '''synchronous''' in the following cases:
-# It is a non-separate call.
-# It is a separate call to a query.
-# It is a feature call which has at least one actual argument which is a separate argument of the enclosing routine.
+
+:1  It is a non-separate call.
+:2  It is a separate call:
+::2.1  To a query, or
+::2.2  To a command which has at least one actual argument which is of a reference type and either
+:::2.2.1  A separate argument of the enclosing routine, or  
+:::2.2.2  <code>Current</code>.
 
 A feature call is '''asynchronous''' in the following case:
-# It is a separate call to a command.
+:1  It is a separate call to a command with no arguments, or arguments not meeting the criteria of 2.2 in the '''synchronous''' case above.
 
 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, non-separate calls will likely occur, and these will be synchronous.
+Case 1 is the case of typical sequential Eiffel, where all calls are non-separate, and therefore synchronous. Of course, even in concurrent Eiffel, non-separate calls will occur, and these will be synchronous.
 
-Case 2 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.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 3 describes a situation which a call provides an actual argument which is a separate formal argument of the call’s enclosing routine. In this case, the enclosing routine has a lock on the processor for the separate argument. So, passing that separate argument to a second feature requires the lock to be passed as well. This is called ''lock passing''. It requires that the call be synchronous, because the call has passed away necessary locks, so subsequent instructions cannot continue before the locks passed are restored to their previous states.
+Case 2.2 describes a situation which a call provides an actual argument which is <code>Current</code> or is a separate formal argument of the call’s enclosing routine. This is the case the client is calling a procedure and passing arguments which are controlled from the client's viewpoint. That is they are objects upon which the client has exclusive access in the enclosing routine. In this case, the client must provide the supplier's processor with the access to these objects. This is done through a mechanism called ''lock passing''. Because the client has passed its locks to the suppliers 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. 
 
-Separate calls to commands are asynchronous. 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 2.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. 
 
 It is in this case that concurrent computation is achieved. The processor of the client object is free to continue processing while the processor handling the target of the asynchronous feature call applies that feature.