The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

multiple job queues

I am currently designing a measurement system and wondering if someone can help me with a clean design for the following scenario.  I'm not the multithreading expert and don't want to start running down a rat hole.

I've got a number of hardware jobs, let's call 'em MoveJob, AlignJob and MeasurementJob.  The hardware is a singleton, so all these jobs must be processed sequentially.

Additionally, I have analysis jobs that follow the measurement jobs.  Sometimes  these are asynch and other times they need to be synchronous.

Let's say each of the jobs inherit from a single method interface, with the method DoWork().

Is it kosher to queue the hardware jobs up and have the MeasurementJob either add Analysis jobs to an analysis job queue or perform the analysis synchronously?

Any suggestions?

...sorry if I'm the only one who can follow this e-mail...
Scott Penner Send private email
Friday, February 02, 2007
 
 
"...so all these jobs must be processed sequentially."

For this reason, I wouldn't queue jobs per se. Let me change the vocabulary around a bit. Let's say I have a work order - cut this pattern - and the work order itself is executed by doing the analyze, move, align, measure jobs.

Work orders can be queued, and you can use a variety of scheduling mechanisms to minimize the average wait time for a work order to be completed. But once you actually start the work, you still have to do all the jobs in sequence. You can pause a job and its parent work order, go do some other work order, come back and resume the paused one, but you can't change the order of the jobs themselves within a work order.

Here's where things get tricky.

Sometimes you can do multiple analysis jobs in parallel with a single move-align-cut job. But what you're really doing is...

Start Work Order A. Complete analyze, move, align and start cutting.

Start Work Order B. Complete analyze, then pause and wait until the mover is free.

Start Work Order C. Complete analyze, then pause and wait til the mover is free.

Finish cutting on A, measure and complete the work order.

Resume Work Order B, move, align, and start cutting.

Start Work Order D, Complete analyze, then pause and wait til the mover is free.

Finish B, resume C.

And so on.

So you have a work queue (and can move work items around) but within each work queue, you don't really have a job queue - you just simply perform jobs in a fixed order.

Hope that helps?
TheDavid
Friday, February 02, 2007
 
 
> so all these jobs must be processed sequentially.

Then why have separate jobs? Just process them all in one job from one queue that has a few different threads sucking work of the queue.

Have a separate queue/threads for the work that can be done aysnc.
son of parnas
Saturday, February 03, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz