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

Set some space which were missing after crlf into script language but not shown on rendered page. So I replaced the crlf by a space character. Maybe a fix of generated code should be if there is only on crlf in parsed code a space should be added after a point.

Browse Source 
Updated wikipage Asynchronous Calls.
	(Signed-off-by:phgachoud).

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2235 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2020-02-13 16:00:53 +00:00
parent da837636bc
commit 1c15ff7916
1 changed files with 5 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
documentation/19.12/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki
View File

@@ -1,3 +1,5 @@
[[Property:modification_date|Thu, 13 Feb 2020 16:00:53 GMT]]
[[Property:publication_date|Thu, 13 Feb 2020 16:00:53 GMT]]
[[Property:title|Asynchronous Calls]]
[[Property:weight|6]]
[[Property:uuid|d3d3873c-5c84-7566-547e-1ede38544081]]
@@ -87,13 +89,10 @@ end
</code>
You might notice a problem here:
In the feature <code>{EXAMPLE}.run</code>, exclusive access to 'a_hash_storage' and 'a_string' is guaranteed by the SCOOP semantics.
Or in other words, the corresponding regions are ''locked''. The feature <code>{HASH_STORAGE}.set_hash_code</code> however needs access to ''a_string'' as well.
In the SCOOP model, as seen so far, this would result in a deadlock. The handler of the <code>HASH_STORAGE</code> object waits for exclusive access on the string object, and the <code>EXAMPLE</code> object waits for the query <code>{HASH_STORAGE}.hash_code</code> to return.
In the feature <code>{EXAMPLE}.run</code>, exclusive access to 'a_hash_storage' and 'a_string' is guaranteed by the SCOOP semantics.
Or in other words, the corresponding regions are ''locked''. The feature <code>{HASH_STORAGE}.set_hash_code</code> however needs access to ''a_string'' as well. In the SCOOP model, as seen so far, this would result in a deadlock. The handler of the <code>HASH_STORAGE</code> object waits for exclusive access on the string object, and the <code>EXAMPLE</code> object waits for the query <code>{HASH_STORAGE}.hash_code</code> to return.
To resolve this problem, SCOOP implements a technique called ''Lock Passing''.
Locks on regions can be passed to the handler of the target of a separate call.
Lock passing happens whenever the client processor (the handler of the <code>EXAMPLE</code> object) has locked a region that holds an object which is passed as an actual argument to a separate call. Note that this also includes non-separate reference objects, because a processor always holds a lock over its own region.
To resolve this problem, SCOOP implements a technique called ''Lock Passing''. Locks on regions can be passed to the handler of the target of a separate call. Lock passing happens whenever the client processor (the handler of the <code>EXAMPLE</code> object) has locked a region that holds an object which is passed as an actual argument to a separate call. Note that this also includes non-separate reference objects, because a processor always holds a lock over its own region.
When a 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 given back the locks to the client. Therefore, this type of call must be synchronous.