From 88d7e65b55d918bd0015e53907a4ea2e249c0a0a Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Thu, 31 Mar 2016 20:00:33 +0000 Subject: [PATCH] updated wiki name for Concurrent programming with SCOOP git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1503 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../eiffel-programming-language-reserved-words.wiki | 2 +- ...major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki | 2 +- ...-standard-ecma-367-and-eiffel-software-implementation.wiki | 2 +- .../general-target-options/index.wiki | 2 +- .../scoop-examples/dining-philosophers.wiki | 2 +- .../concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki | 2 +- .../scoop-examples/producer-consumer.wiki | 4 ++-- .../concurrent-eiffel-scoop/scoop-examples/quicksort.wiki | 2 +- .../scoop-examples/search-insert-delete.wiki | 2 +- .../concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki | 4 ++-- .../scoop-examples/single-element-producer-consumer.wiki | 4 ++-- .../concurrent-eiffel-scoop/scoop-implementation.wiki | 4 ++-- 12 files changed, 16 insertions(+), 16 deletions(-) diff --git a/documentation/trunk/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki b/documentation/trunk/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki index eb4d1d80..bfafcd16 100644 --- a/documentation/trunk/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki +++ b/documentation/trunk/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki @@ -429,7 +429,7 @@ Used in an [[Eiffel programming language syntax#Inheritance parts|inheritance pa Reserved for future use. -{{Note|Used in EiffelStudio implementations version 6.8 and later to support [[Concurrent Eiffel with SCOOP]].}} +{{Note|Used in EiffelStudio implementations version 6.8 and later to support [[Concurrent programming with SCOOP]].}} ===then=== diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki index 22fdf5c2..bd90e23b 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki @@ -3,7 +3,7 @@ [[Property:weight|-15]] [[Property:uuid|4ae502ce-5832-c323-4c3a-d1b0d1243735]] ==What's new== -* Support for [[Concurrent Eiffel with SCOOP|SCOOP concurrency model]]. +* Support for [[Concurrent programming with SCOOP|SCOOP concurrency model]]. {{seealso|
1) SCOOP implementation [[SCOOP implementation#Known limitations|limitations]].
2) [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]]. }} ==Improvements== diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki index 7bb94d8b..5928c143 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki @@ -244,7 +244,7 @@ reattachment | Yes, by option ''void_safety'' |} -==[[Concurrent Eiffel with SCOOP|SCOOP]]== +==[[Concurrent programming with SCOOP|SCOOP]]== {| class="doctable" |- !
'''Feature'''
diff --git a/documentation/trunk/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki b/documentation/trunk/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki index b3e6eae6..b6cf74cf 100644 --- a/documentation/trunk/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki +++ b/documentation/trunk/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki @@ -53,6 +53,6 @@ Further options are * Full Class Checking, Void-safety, Are types attached by default?: These settings are generally associated with increasing the safety of compiled code, particularly [[Creating a new void-safe project#Project settings for void-safe projects|void-safety]]. * Cat call detection: Attempts to identify at compile time the possibility of the system making a [[ET: Inheritance#Catcalls|catcall]]. * Syntax: Allows you to select the [[Setting the syntax variant|syntax variant]] used by the compiler when compiling this target. -* Concurrency: Controls the level of concurrency support for this target. ''No concurrency'' means mono-threaded; ''EiffelThread'' means concurrent threads using the [[EiffelThread Tutorial|EiffelThread]] library. ''SCOOP'' means concurrency based on the [[Concurrent Eiffel with SCOOP|SCOOP]] rules. +* Concurrency: Controls the level of concurrency support for this target. ''No concurrency'' means mono-threaded; ''EiffelThread'' means concurrent threads using the [[EiffelThread Tutorial|EiffelThread]] library. ''SCOOP'' means concurrency based on the [[Concurrent programming with SCOOP|SCOOP]] rules. diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki index 0c68aa48..caca96b4 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki @@ -28,7 +28,7 @@ Class PHILOSOPHER models the philosophers. The totality of a philos This feature is called by {PHILOSOPHER}.live repeatedly until the philosopher has eaten a prescribed number of times. -The feature think requires no access to shared objects, but the feature eat depends upon the philosopher's ability to secure access to both of the forks adjacent to his plate. Because all forks are separate objects, each call to eat waits until the processors for both the left and right forks are available (in accordance with the [[Concurrent Eiffel with SCOOP#Access to shared resources|Wait rule]]). +The feature think requires no access to shared objects, but the feature eat depends upon the philosopher's ability to secure access to both of the forks adjacent to his plate. Because all forks are separate objects, each call to eat waits until the processors for both the left and right forks are available (in accordance with the [[Concurrent programming with SCOOP#Access to shared resources|Wait rule]]). Another interesting feature of this example is the feature {PHILOSOPHER}.eat. If you look at the text of this feature diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki index 0d317473..abf27f97 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki @@ -12,7 +12,7 @@ The scenario in the Faneuil Hall example involves a number of immigrants waiting The primary actors here are the immigrants, the judge, and the spectators, model by classes IMMIGRANT, JUDGE, and SPECTATOR, respectively. In addition to the actor classes, there is a class HALL that represents Faneuil Hall itself, and a root class that sets everything up and starts the processing. There is only one judge. But there can be many immigrants and spectators. Their numbers are limited to certain maximums specified by constants in the root class. The specific number of immigrants and spectators varies at random from one execution to the next. You can experiment with larger or smaller maximum numbers for immigrants and spectators by changing the values for the constants {FANEUIL_HALL}.Max_immigrants and {FANEUIL_HALL}.Max_spectators. -Although not really considered an actor here, the class HALL plays a critical role in synchronizing the concurrent actions of the immigrants, spectators, and the judge. HALL includes many status queries which, when used in preconditions in features of the other actors, constitute [[Concurrent Eiffel with SCOOP#Preconditions|uncontrolled precondition clauses]] which when false will cause the calling processor to wait until the condition becomes true. For example, consider the following status query from class HALL: +Although not really considered an actor here, the class HALL plays a critical role in synchronizing the concurrent actions of the immigrants, spectators, and the judge. HALL includes many status queries which, when used in preconditions in features of the other actors, constitute [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition clauses]] which when false will cause the calling processor to wait until the condition becomes true. For example, consider the following status query from class HALL: immigrants_ready: BOOLEAN diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki index 5bdc62bc..b47f803b 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki @@ -32,11 +32,11 @@ It might occur to you that it would be easier, simpler, and clearer just to incl in place of the call to launch_producer, and dispense with the launch_producer feature entirely. But that is not possible in this case. -The reason is that a_producer.produce (900) is a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to a_producer is declared of a separate type), and according to the [[Concurrent Eiffel with SCOOP#Access to shared resources|separate argument rule]], calls on a separate object are valid only when applied to an argument of the enclosing routine. +The reason is that a_producer.produce (900) is a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to a_producer is declared of a separate type), and according to the [[Concurrent programming with SCOOP#Access to shared resources|separate argument rule]], calls on a separate object are valid only when applied to an argument of the enclosing routine. ==Wait condition== -This example also shows an [[Concurrent Eiffel with SCOOP#Preconditions|uncontrolled precondition]] serving as a "wait condition". In the class PRODUCER we see the buffer declared as a class attribute with a separate type: +This example also shows an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]] serving as a "wait condition". In the class PRODUCER we see the buffer declared as a class attribute with a separate type: buffer: separate BOUNDED_BUFFER [INTEGER] diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki index ad89b1ab..e64b4837 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki @@ -6,7 +6,7 @@ The quicksort example is a concurrent implementation of the well-known [http://en.wikipedia.org/wiki/Quicksort quicksort] sorting algorithm developed by computer scientist [http://en.wikipedia.org/wiki/C._A._R._Hoare C. A. R. Hoare]. Quicksort uses a "divide and conquer" strategy to sort a structure. It applies a basic algorithm to the structure which leads to a division of the elements into to two substructures. Then it applies the same algorithm to each of the substructures, and so on, until the whole structure is sorted. Because of the repetitive application of the same algorithm to evolving parts of the structure, the quicksort is often used in computer science classes to provide students with experience in [http://en.wikipedia.org/wiki/Recursion_(computer_science) recursive] computation. -In the SCOOP example, instead of recursive calls, substructures are handled (within limits) by separate [[Concurrent Eiffel with SCOOP|SCOOP processors]] running concurrently. +In the SCOOP example, instead of recursive calls, substructures are handled (within limits) by separate [[Concurrent programming with SCOOP|SCOOP processors]] running concurrently. =Highlights= diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki index 8e64641b..f81dc6ba 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki @@ -38,7 +38,7 @@ These are used in the can_search, can_insert, and -For the deleter calling {SHARED_LIST}.start_delete, the precondition clause can_delete is an [[Concurrent Eiffel with SCOOP#Preconditions|uncontrolled precondition]]. This means that the deleter will wait until the can_delete becomes true before feature application of start_delete occurs. +For the deleter calling {SHARED_LIST}.start_delete, the precondition clause can_delete is an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]]. This means that the deleter will wait until the can_delete becomes true before feature application of start_delete occurs. diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki index 9110c499..cd3604e2 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki @@ -14,9 +14,9 @@ The root class for this example creates the bus stop, the bus, and the passenger The bus stop, modeled by class STATION has features that can be used by the bus and by passengers. Access to these features is restricted to the appropriate client classes through the clients part of the feature clause. Clients of type PASSENGER can access {STATION}.pass_enter. A client of type BUS can access {STATION}.bus_enter, {STATION}.pick_up, and {STATION}.leave, as well as a status feature {STATION}.bus_is_waiting and two passenger queues {STATION}.waiting_list and {STATION}.checked_in_list. -The lifecycle of a passenger is simple: enter the bus stop. This is accomplished by making a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] to {STATION}.enter and passing Current (the passenger object itself) as an argument. +The lifecycle of a passenger is simple: enter the bus stop. This is accomplished by making a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] to {STATION}.enter and passing Current (the passenger object itself) as an argument. -The lifecycle of the bus is slightly more complex: enter the bus stop, pick up passengers, leave the bus stop, wait for a short time. The bus repeats this sequence forever. The routines in class BUS for entering the bus stop, picking up passengers, and leaving the bus stop all accept as an argument the separate bus stop object (a_station: separate STATION) and make a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] to the corresponding routine in STATION. +The lifecycle of the bus is slightly more complex: enter the bus stop, pick up passengers, leave the bus stop, wait for a short time. The bus repeats this sequence forever. The routines in class BUS for entering the bus stop, picking up passengers, and leaving the bus stop all accept as an argument the separate bus stop object (a_station: separate STATION) and make a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] to the corresponding routine in STATION. Features of the bus stop (class STATION) manage the queues for waiting and checked-in passengers and whether a bus is at the bus stop. Passengers are added to the waiting queue when they arrive at the station. When the bus leaves the station, any waiting passengers are transferred to the checked-in queue. When the bus arrives at the station, the passengers on the checked-in queue are allowed to board the bus (up to the first 50 passengers, that is), and the boarding passengers are then removed from the checked-in queue. diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki index 947cbe64..81d1e6a0 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki @@ -3,7 +3,7 @@ [[Property:uuid|25d3e585-0eb6-efa8-ada9-8ee596df5ada]] =Description= -The single-element producer-consumer is a simpler variant of the classic [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem. A producer produces products, in this case integers, into a single-element inventory. The products are then consumed from inventory by a consumer. The producer, consumer, and inventory are managed by separate [[Concurrent Eiffel with SCOOP#Processors|processors]], so any access they have to one another must be synchronized through scoop mechanisms. +The single-element producer-consumer is a simpler variant of the classic [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem. A producer produces products, in this case integers, into a single-element inventory. The products are then consumed from inventory by a consumer. The producer, consumer, and inventory are managed by separate [[Concurrent programming with SCOOP#Processors|processors]], so any access they have to one another must be synchronized through scoop mechanisms. =Highlights= @@ -11,7 +11,7 @@ In the single-element producer-consumer only a single producer and single consum The classes modeling the different actors have obvious names: PRODUCER, CONSUMER, and INVENTORY. The root class of the example creates one separate instance of each of these, and then brings the producer and consumer to life. -The PRODUCER class supports a procedure produce in which a product is produced and stored in the single-element INVENTORY. The producer can only produce an element if the inventory is currently empty. Class INVENTORY exports a boolean query has_item which is the indicator of whether a product has been produced and is available for consumption. So {PRODUCER}.produce has a precondition that depends upon {INVENTORY}.has_item being false. Because the inventory is handled by a separate processor, this precondition is [[Concurrent Eiffel with SCOOP#Preconditions|uncontrolled]] and will cause the producer to wait until the condition is true to proceed. +The PRODUCER class supports a procedure produce in which a product is produced and stored in the single-element INVENTORY. The producer can only produce an element if the inventory is currently empty. Class INVENTORY exports a boolean query has_item which is the indicator of whether a product has been produced and is available for consumption. So {PRODUCER}.produce has a precondition that depends upon {INVENTORY}.has_item being false. Because the inventory is handled by a separate processor, this precondition is [[Concurrent programming with SCOOP#Preconditions|uncontrolled]] and will cause the producer to wait until the condition is true to proceed. The CONSUMER class works in a way that is largely the symmetrical opposite of PRODUCER. The consumer tries to consume the item from the INVENTORY. But this only possible if an item has been produced and is available. So {CONSUMER}.consume has a "wait" precondition based on the query {INVENTORY}.has_item. diff --git a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki index a1b922f0..03ab7ef2 100644 --- a/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki +++ b/documentation/trunk/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki @@ -15,7 +15,7 @@ The differences between the EiffelStudio implementation of SCOOP and current and ==Supported concurrency mechanisms== -Although the SCOOP model can support virtually any underlying concurrency mechanism, the initial SCOOP implementation in EiffelStudio version 6.8 supports only one executable, using multiple process threads as SCOOP [[Concurrent Eiffel with SCOOP#Processors|processors]]. +Although the SCOOP model can support virtually any underlying concurrency mechanism, the initial SCOOP implementation in EiffelStudio version 6.8 supports only one executable, using multiple process threads as SCOOP [[Concurrent programming with SCOOP#Processors|processors]]. ==Maximum number of SCOOP processors== @@ -133,7 +133,7 @@ set_tuple_string (a_tuple: separate TUPLE [str: separate STRING]; a_string: sepa {{note | This only applies to EiffelStudio releases prior to 15.01}} -The [[Concurrent Eiffel with SCOOP#Access to shared resources|Wait Rule]] says: ''A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine.'' +The [[Concurrent programming with SCOOP#Access to shared resources|Wait Rule]] says: ''A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine.'' In the EiffelStudio implementation prior to 15.01, a routine will not necessarily wait for all processors associated with its separate arguments to be available before it ''begins'' execution. The waiting on processors occurs in a "lazy" manner. Execution will only wait on the availability of one of the processors when it actually needs to use the argument associated with that processor. This means that if there are several instructions ahead of the first instruction that references a separate argument, then those several instructions will be executed immediately. Only at the point at which the separate argument's processor is needed will the routine pause and wait for the availability of the processor.