mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-06 23:02:28 +01:00
updated wiki name for Concurrent programming with SCOOP
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1503 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
@@ -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===
|
||||
|
||||
@@ -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|<br/>1) SCOOP implementation [[SCOOP implementation#Known limitations|limitations]].<br/>2) [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]]. }}
|
||||
|
||||
==Improvements==
|
||||
|
||||
@@ -244,7 +244,7 @@ reattachment
|
||||
| Yes, by option ''void_safety''
|
||||
|}
|
||||
|
||||
==[[Concurrent Eiffel with SCOOP|SCOOP]]==
|
||||
==[[Concurrent programming with SCOOP|SCOOP]]==
|
||||
{| class="doctable"
|
||||
|-
|
||||
! <center>'''Feature'''</center>
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Class <code>PHILOSOPHER</code> models the philosophers. The totality of a philos
|
||||
|
||||
This feature is called by <code>{PHILOSOPHER}.live</code> repeatedly until the philosopher has eaten a prescribed number of times.
|
||||
|
||||
The feature <code>think</code> requires no access to shared objects, but the feature <code>eat</code> 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 <code>eat</code> 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 <code>think</code> requires no access to shared objects, but the feature <code>eat</code> 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 <code>eat</code> 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 <code>{PHILOSOPHER}.eat</code>. If you look at the text of this feature
|
||||
|
||||
|
||||
@@ -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 <code>IMMIGRANT</code>, <code>JUDGE</code>, and <code>SPECTATOR</code>, respectively. In addition to the actor classes, there is a class <code>HALL</code> 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 <code>{FANEUIL_HALL}.Max_immigrants</code> and <code>{FANEUIL_HALL}.Max_spectators</code>.
|
||||
|
||||
Although not really considered an actor here, the class <code>HALL</code> plays a critical role in synchronizing the concurrent actions of the immigrants, spectators, and the judge. <code>HALL</code> 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 <code>HALL</code>:
|
||||
Although not really considered an actor here, the class <code>HALL</code> plays a critical role in synchronizing the concurrent actions of the immigrants, spectators, and the judge. <code>HALL</code> 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 <code>HALL</code>:
|
||||
|
||||
<code>
|
||||
immigrants_ready: BOOLEAN
|
||||
|
||||
@@ -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 <code>launch_producer</code>, and dispense with the <code>launch_producer</code> feature entirely. But that is not possible in this case.
|
||||
|
||||
The reason is that <code>a_producer.produce (900)</code> is a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to <code>a_producer</code> 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 <code>a_producer.produce (900)</code> is a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to <code>a_producer</code> 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 <code>PRODUCER</code> we see the buffer declared as a class attribute with a <code>separate</code> type:
|
||||
This example also shows an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]] serving as a "wait condition". In the class <code>PRODUCER</code> we see the buffer declared as a class attribute with a <code>separate</code> type:
|
||||
|
||||
<code>
|
||||
buffer: separate BOUNDED_BUFFER [INTEGER]
|
||||
|
||||
@@ -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=
|
||||
|
||||
@@ -38,7 +38,7 @@ These are used in the <code>can_search</code>, <code>can_insert</code>, and <cod
|
||||
end
|
||||
</code>
|
||||
|
||||
For the deleter calling <code>{SHARED_LIST}.start_delete</code>, the precondition clause <code>can_delete</code> is an [[Concurrent Eiffel with SCOOP#Preconditions|uncontrolled precondition]]. This means that the deleter will wait until the <code>can_delete</code> becomes true before feature application of <code>start_delete</code> occurs.
|
||||
For the deleter calling <code>{SHARED_LIST}.start_delete</code>, the precondition clause <code>can_delete</code> is an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]]. This means that the deleter will wait until the <code>can_delete</code> becomes true before feature application of <code>start_delete</code> occurs.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 <code>STATION</code> 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 <code>PASSENGER</code> can access <code>{STATION}.pass_enter</code>. A client of type <code>BUS</code> can access <code>{STATION}.bus_enter</code>, <code>{STATION}.pick_up</code>, and <code>{STATION}.leave</code>, as well as a status feature <code>{STATION}.bus_is_waiting</code> and two passenger queues <code>{STATION}.waiting_list</code> and <code>{STATION}.checked_in_list</code>.
|
||||
|
||||
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 <code>{STATION}.enter</code> and passing <code>Current</code> (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 <code>{STATION}.enter</code> and passing <code>Current</code> (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 <code>BUS</code> for entering the bus stop, picking up passengers, and leaving the bus stop all accept as an argument the separate bus stop object (<code>a_station: separate STATION</code>) and make a [[Concurrent Eiffel with SCOOP#Separate types and separate calls|separate call]] to the corresponding routine in <code>STATION</code>.
|
||||
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 <code>BUS</code> for entering the bus stop, picking up passengers, and leaving the bus stop all accept as an argument the separate bus stop object (<code>a_station: separate STATION</code>) and make a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] to the corresponding routine in <code>STATION</code>.
|
||||
|
||||
Features of the bus stop (class <code>STATION</code>) 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.
|
||||
|
||||
|
||||
@@ -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: <code>PRODUCER</code>, <code>CONSUMER</code>, and <code>INVENTORY</code>. The root class of the example creates one <code>separate</code> instance of each of these, and then brings the producer and consumer to life.
|
||||
|
||||
The <code>PRODUCER</code> class supports a procedure <code>produce</code> in which a product is produced and stored in the single-element <code>INVENTORY</code>. The producer can only produce an element if the inventory is currently empty. Class <code>INVENTORY</code> exports a boolean query <code>has_item</code> which is the indicator of whether a product has been produced and is available for consumption. So <code>{PRODUCER}.produce</code> has a precondition that depends upon <code>{INVENTORY}.has_item</code> 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 <code>PRODUCER</code> class supports a procedure <code>produce</code> in which a product is produced and stored in the single-element <code>INVENTORY</code>. The producer can only produce an element if the inventory is currently empty. Class <code>INVENTORY</code> exports a boolean query <code>has_item</code> which is the indicator of whether a product has been produced and is available for consumption. So <code>{PRODUCER}.produce</code> has a precondition that depends upon <code>{INVENTORY}.has_item</code> 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 <code>CONSUMER</code> class works in a way that is largely the symmetrical opposite of <code>PRODUCER</code>. The consumer tries to <code>consume</code> the item from the <code>INVENTORY</code>. But this only possible if an item has been produced and is available. So <code>{CONSUMER}.consume</code> has a "wait" precondition based on the query <code>{INVENTORY}.has_item</code>.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user