From e4c7bc968373829327f729db646a5192c7b10b6c Mon Sep 17 00:00:00 2001 From: halw Date: Fri, 25 Mar 2011 18:07:42 +0000 Subject: [PATCH] Updated to correspond to updated example (build 85949). Author:halw Date:2011-03-25T18:07:42.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@858 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../single-element-producer-consumer.wiki | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki index bf30491d..ab5de687 100644 --- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki +++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki @@ -7,21 +7,19 @@ =Description= -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 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 Eiffel with SCOOP#Processors|processors]], so any access they have to one another must be synchronized through scoop mechanisms. =Highlights= -In the single-element producer-consumer only a single producer and single consumer are created, and there is only storage allowing for a single instance of the 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. +In the single-element producer-consumer only a single producer and single consumer are created, and there is only storage allowing for a single instance of the product. So, effectively in this example, the bounded buffer of the classic producer-consumer problem has a size of one. -The PRODUCER class interface exposes features make_something in which a product is produced and get_something: INTEGER which allows a consumer to retrieve the latest product, if one is available. Feature has_something: BOOLEAN is the indicator of whether an integer has been produced and is available for consumption. +The classes modeling the different actors have obvious names: PRODUCER, CONSUMER, and INVENTORY. The root class of the example creates one separate instance of each of these, and then brings the producer and consumer to life. -The CONSUMER class has a feature take that consumes a product from the producer (by calling {PRODUCER}.get_something), if a product exists. The precondition for take is based on {PRODUCER}.has_something. This is an [[Concurrent Eiffel with SCOOP#Design by Contract and SCOOP|uncontrolled precondition]], so instances of CONSUMER are not obliged to ensure that it holds before calling take. Rather, under SCOOP, this precondition will ensure that the application of take waits until the producer does have a product available for consumption. +The PRODUCER class supports a procedure produce in which a product is produced and stored in the single-element INVENTORY. The producer can only produce an element if the inventory is currently empty. Class INVENTORY exports a boolean query has_item which is the indicator of whether a product has been produced and is available for consumption. So {PRODUCER}.produce has a precondition that depends upon {INVENTORY}.has_item 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. -Likewise, there is an uncontrolled precondition on {PRODUCER}.make_something that allows the feature to be applied only when has_something does not hold. +The CONSUMER class works in a way that is largely the symmetrical opposite of PRODUCER. The consumer tries to consume the item from the INVENTORY. But this only possible if an item has been produced and is available. So {CONSUMER}.consume has a "wait" precondition based on the query {INVENTORY}.has_item. -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 APPLICATION declares a PRODUCER and a CONSUMER, both separate. APPLICATION starts the example running by creating the producer and consumer, then by looping calls to the {PRODUCER}.make_something requesting it constantly to produce products. +So the heart of the problem is the synchronization between producer and consumer sharing a single inventory. If there's already a product in inventory, the producer cannot produce more and must wait. Only when the consumer consumes the current product can the producer produce again. For the consumer's part, if there's a product currently in inventory, then the consumer can consume that product. Otherwise, the consumer must wait until the producer produces a new product. The synchronization is handled by the SCOOP mechanism of wait preconditions on the inventory.