mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-08 07:42:33 +01:00
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:
@@ -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.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user