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

Author:halw

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


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@752 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2011-02-08 16:45:50 +00:00
parent b37244193a
commit 8cf0000c3a
3 changed files with 25 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki Normal file
View File

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

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

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