From ad984e89c0a5c8031f8e640ad8b343ef5b76979a Mon Sep 17 00:00:00 2001 From: halw Date: Fri, 15 Apr 2011 20:56:51 +0000 Subject: [PATCH] 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 --- .../concurrent-eiffel-scoop/index.wiki | 20 +++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) 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 cbee1155..a4042dec 100644 --- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki +++ b/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 Current. 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 Current 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.