[concurrency-interest] j.u.c/backport performance on Windows
szabolcs.ferenczi at gmail.com
Tue Apr 3 03:01:14 EDT 2007
On 02/04/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> From this perspective, I am not sure how I could maintain the required
> semantics whithout the the equivalent of an inputProducerLock. Please,
> let me know, what you think.
What is the semantics you refer to?
This is how it looks like to me until now. In this arrangement you
define one consumer that is consuming from a single FIFO
"outputQueue". The FIFO is filled by N producers called
workers. Workers fetch items from a collection with help of a shared
iterator "inputProducer". Workers do nothing else but wrap the fetched
items into work units and push them into the FIFO queue.
The semantics you are trying to maintain is that the order of items
referred to by the iterator "inputProducer" must be the same as the
order of the corresponding work units in the FIFO "outputQueue". You
can easily maintain it by applying one single worker that takes items
with help of the iterator "inputProducer", wraps them into work units,
and pushes them into the FIFO "outputQueue". It looks like there is no
need for many workers of this kind. Hence, the semantics is maintained.
I might miss something from the story. How are the items in the
collection created? I mean the collection which is traversed by the
workers with help of the shared iterator. I guess that is the real
producer action and not what the workers do. Am I right in that? If
yes, the real producers should put their results into the FIFO right
away and the "semantics problem" is gone. Does this help?
More information about the Concurrency-interest