> May be faster to have the main build a queue of records and let the
subtasks
> feed themselves. There are interesting serialization concerns with
multiple
> eaters. The feeder can post all waiting tasks when food is available.
I know this is a very old thread...
I have been re-reading it simply because I am "looking for a better way".
Does anybody know of any real good documentation on subtask usage as it
relates to, what Binyamin called, "single feeder, multiple eater"
processing? Including the queuing of requests.
Or examples. I have scanned the CBT tape, but I did not spot any that
indicated they used such.
Tony Thigpen
-----Original Message -----
From: Binyamin Dissen
Sent: 04/10/2011 11:51 AM
On Sun, 10 Apr 2011 06:23:15 -0400 Joe Owens <[email protected]>
wrote:
:>After such a great response to my last post, I thought I would try here
:>again for some useful advice on the best design for a program I am about to
:>write.
:>I have a mainline program that reads an input file and will then pass a
:>record to a subtask to process.
May be faster to have the main build a queue of records and let the subtasks
feed themselves. There are interesting serialization concerns with multiple
eaters. The feeder can post all waiting tasks when food is available.
:>The subtask has a work cycle
:>MQPUT messsage
:>MQGET message (with wait option, by corellid, gets the response message)
:>write message to preopened output file.
:>When the mainline program wishes to send another message, it must choose a
:>non-busy subtask, or attach another. The whole point is to drive a certain
:>message rate, so I do not wish to queue more than 1 piece of work to any
:>subtask at a time
The attach has some overhead. Depending on the processing speed, it may take
more time to do the attach than let an existing task become ready.
:>The subtask cycle will take about 150ms. I would like to be able to process
:>up to 300 messages per second, although normal rates would be much lower.
:>So questions;
:>Use pause/release or wait/post?
Pasue/release is probably slightly faster.
:>For the output file write, what would be the best way of serialising the
:>file writes?
As the others have suggested, a queue for the main task, where the subtasks
are feeders.
:>each subtask wraps an enq/deq around the put?
Yuck.
:>Another subtask has a work queue of records to be written which is added to
:>by the other tasks? In this case what is the best scheme for dispatch of
:>this task, when many others may wish to give him work?
Use the main task. And the feeders should post its ECB if it is waiting.
:>Any other comments or suggestions would be appreciated too.
What to do if a subtask is non-responsive, i.e., does not complete within the
expected time?
What to do if a subtask abends handling a request?
What if MQ goes down in the middle?
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
