mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2026-04-05 01:29:28 +02:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2011-02-08T02:34:57.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@752 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2011-02-08 16:45:50 +00:00
parent b37244193a
commit 8cf0000c3a
3 changed files with 25 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

@@ -192,7 +192,7 @@ Case 1 is the case of typical sequential Eiffel, where all calls are non-separat
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 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 can not continue before the locks passed are restored to their previous states.
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.
Now consider the only case, Case 1, determining asynchronous calls.