Author:halw

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


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@752 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki

@@ -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. 
 

documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki

@@ -0,0 +1,22 @@
+[[Property:title|Dining philosophers]]
+[[Property:weight|-12]]
+[[Property:uuid|ec90654b-723a-ed0f-0325-09a8918bfe10]]
+
+
+{{Beta}}
+
+
+
+=Description=
+
+In the [http://en.wikipedia.org/wiki/Dining_philosophers_problem dining philosopers] a number of philosophers (five, in our example) are seated around a circular table. On the table are five plates of food, one in front of each philosopher, and five forks, one between each adjacent pair of plates. So each philosopher has a plate in front of him and a fork to his left and a fork to his right.
+
+The philosophers spend all their time in either of only two states: they are thinking or they are eating. The philosophers may be brilliant thinkers, but apparently manual dexterity is not their strong suit. This is evidenced by the fact that while eating, any philosopher must pick up both of the forks positioned on either side of that philosopher's plate. So, while eating they must have possession of both forks, and while thinking, they have put down any forks that they had previously used. 
+
+
+=Highlights=
+
+
+
+
+

documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki

@@ -1,7 +1,6 @@
 [[Property:title|Single-element producer-consumer]]
 [[Property:weight|-15]]
 [[Property:uuid|25d3e585-0eb6-efa8-ada9-8ee596df5ada]]
-
 {{Beta}}
 
 
@@ -20,6 +19,8 @@ The <code>CONSUMER</code> class has a feature <code>take</code> that consumes a
 
 Likewise, there is an uncontrolled precondition on <code>{PRODUCER}.make_something</code> that allows the feature to be applied only when <code>has_something</code> does not hold.
 
+So the heart of the problem is the synchronization between producer and consumer. If there's already a product in storage, the producer cannot produce more and must wait. Only when the consumer consumes the current product can the producer produce again. On the other side, if there's a product currently in storage with the producer, then the consumer can consume that product. Otherwise, the consumer must wait until the producer produces a new product.
+
 The example's root class <code>APPLICATION</code> declares a <code>PRODUCER</code> and a <code>CONSUMER</code>, both <code>separate</code>. <code>APPLICATION</code> starts the example running by creating the producer and consumer, then by looping calls to the <code>{PRODUCER}.make_something</code> requesting it constantly to produce products.