From 1c15ff7916933e260310967348749da3131f6a31 Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Thu, 13 Feb 2020 16:00:53 +0000 Subject: [PATCH] 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. Updated wikipage Asynchronous Calls. (Signed-off-by:phgachoud). git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2235 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../scoop-asynchronous-calls.wiki | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/documentation/19.12/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki b/documentation/19.12/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki index fd3bc333..b435440e 100644 --- a/documentation/19.12/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki +++ b/documentation/19.12/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki @@ -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 You might notice a problem here: -In the feature {EXAMPLE}.run, 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 {HASH_STORAGE}.set_hash_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 HASH_STORAGE object waits for exclusive access on the string object, and the EXAMPLE object waits for the query {HASH_STORAGE}.hash_code to return. +In the feature {EXAMPLE}.run, 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 {HASH_STORAGE}.set_hash_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 HASH_STORAGE object waits for exclusive access on the string object, and the EXAMPLE object waits for the query {HASH_STORAGE}.hash_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 EXAMPLE 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 EXAMPLE 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.