Author:halw

Date:2011-02-01T19:30:31.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@746 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
pgummer
2011-02-01 22:40:14 +00:00
parent e547255f5d
commit 07d1d9d01b
2 changed files with 19 additions and 2 deletions

View File

@@ -0,0 +1,17 @@
[[Property:title|Single-element producer-consumer]]
[[Property:weight|-15]]
[[Property:uuid|25d3e585-0eb6-efa8-ada9-8ee596df5ada]]
The single-element producer-consumer is a variant of the classic [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem. A producer produces products, in this case integers, which are consumed by a consumer. The producer and consumer are managed by separate [[Concurrent Eiffel with SCOOP#Processors|processors]], so their access to
In this case only a single producer and single consumer are created and there is storage for only a single product. So, effectively in this example, the bounded buffer of the classic producer-consumer problem has a size of one and is not a shared resource. Rather, the single product element (in this case, an integer) is held by the producer and provided to the consumer upon request.
The <code>PRODUCER</code> class interface exposes features <code>make_something</code> in which a product is produced and <code>get_something: INTEGER</code> which allows a consumer to retrieve the latest product, if one is available. Feature <code>has_something: BOOLEAN</code> is the indicator of whether an integer has been produced and is available for consumption.
The <code>CONSUMER</code> class has a feature <code>take</code> that consumes a product from the producer (by calling <code>{PRODUCER}.get_something</code>), if a product exists. The precondition for <code>take</code> is based on <code>{PRODUCER}.has_something</code>. This is an [[Concurrent Eiffel with SCOOP#Design by Contract and SCOOP|uncontrolled precondition]], so instances of <code>CONSUMER</code> are not obliged to ensure that it holds before calling <code>take</code>. Rather, under SCOOP, this precondition will ensure that the application of <code>take</code> waits until the producer does have a product available for consumption.
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.
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.