mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 23:32:42 +01:00
0ef958966d
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2240 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
70 lines
4.1 KiB
Plaintext
70 lines
4.1 KiB
Plaintext
[[Property:title|Producer-consumer]]
|
|
[[Property:weight|-13]]
|
|
[[Property:uuid|03739be2-e0d5-f5f0-b405-0bb75c8fee0f]]
|
|
|
|
=Description=
|
|
|
|
The [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem is a classic software concurrency problem. The problem features one or more "producers" and one or more "consumers". All producers and consumers must share access to a "buffer" into which producers insert the products they produce, and from which consumers take the products they consume. The shared buffer is "bounded", that is, it has a maximum capacity.
|
|
|
|
So at any time, the buffer could be empty, precluding any consumer from withdrawing a product. Or the buffer could be full, which would mean that no producer could produce a new product until a consumer had first consumed a product, making space in the buffer. To avoid concurrency related problems, producers and consumers can access the buffer only at times when no other producer or consumer is accessing it, and only when it is in the proper state for the particular type requesting access (i. e., not empty for consumers and not full for producers).
|
|
|
|
=Highlights=
|
|
|
|
The root class of the example creates the bounded product buffer and a number of producers and consumers, all given <code>separate</code> types. It requests the producers to create a number of products, and the consumers, in the aggregate, to consume that same number of products.
|
|
|
|
==Separate argument rule==
|
|
|
|
Notice that the root class uses a feature <code>launch_producer</code> (and a corresponding feature <code>launch_consumer</code>) for instructing the producers and consumers on how many products to handle. <code>launch_producer</code> looks like this:
|
|
|
|
<code>
|
|
launch_producer (a_producer: separate PRODUCER)
|
|
-- Launch `a_producer'.
|
|
do
|
|
a_producer.produce (900)
|
|
end
|
|
</code>
|
|
|
|
It might occur to you that it would be easier, simpler, and clearer just to include this feature's single procedural line:
|
|
|
|
<code>
|
|
a_producer.produce (900)
|
|
</code>
|
|
|
|
in place of the call to <code>launch_producer</code>, and dispense with the <code>launch_producer</code> feature entirely. But that is not possible in this case.
|
|
|
|
The reason is that <code>a_producer.produce (900)</code> is a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to <code>a_producer</code> is declared of a separate type), and according to the [[Concurrent programming with SCOOP#Access to shared resources|separate argument rule]], calls on a separate object are valid only when applied to an argument of the enclosing routine.
|
|
|
|
==Wait condition==
|
|
|
|
This example also shows an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]] serving as a "wait condition". In the class <code>PRODUCER</code> we see the buffer declared as a class attribute with a <code>separate</code> type:
|
|
|
|
<code>
|
|
buffer: separate BOUNDED_BUFFER [INTEGER]
|
|
-- Shared product buffer.
|
|
</code>
|
|
|
|
The feature <code>store</code> contains a precondition which ensures that the shared buffer is not full when <code>store</code> gets applied:
|
|
|
|
<code>
|
|
store (a_buffer: separate BOUNDED_BUFFER [INTEGER]; an_element: INTEGER)
|
|
-- Store `an_element' into `a_buffer'.
|
|
require
|
|
not a_buffer.is_full
|
|
do
|
|
a_buffer.put (an_element)
|
|
ensure
|
|
not a_buffer.is_empty
|
|
a_buffer.count = old a_buffer.count + 1
|
|
end
|
|
</code>
|
|
|
|
The <code>store</code> routine is called by the routine <code>produce</code>, passing a reference to the <code>separate</code> attribute <code>buffer</code> like this:
|
|
|
|
<code>
|
|
store (buffer, l_element)
|
|
</code>
|
|
|
|
Because <code>buffer</code> is considered uncontrolled in the context of <code>produce</code>, then the precondition for <code>store</code> becomes a wait condition, rather than a correctness condition. This means that if the buffer is full, then the application of the feature <code>store</code> will wait until some consumer removes an product from the buffer. The removal of a product makes the precondition hold again, and the application of <code>store</code> can proceed.
|
|
|
|
|