[dmd-concurrency] priority messages

[Kevin Bealer]

On Mon, Jan 25, 2010 at 12:21 PM, Michel Fortin
<michel.fortin at michelf.com>wrote:

> Le 2010-01-25 à 11:36, Kevin Bealer a écrit :
>
> > Are you also considering multiple levels of priority?  In the reader /
> > processor / writer case, I can think of several priorities the processor
> > might want:
> >
> > 1. Normal -- here is another buffer to write.
> > 2. Medium -- the file read failed, stop with this file.
> > 3. Medium#2 -- too much information too fast, please stop sending until
> > further notice.
> > 4. High -- The system is going down, pack up and get out of dodge
> >
> > I'm not sure if #2 and #3 need to be at different levels, but it seems
> like
> > 1, (2 or 3), and 4 should be distinct.  E.g. you don't care about either
> > Medium if there is a High in the pipe and you want to process Normals
> after
> > any High or Medium is handled.
> >
> > This argues for a many-level approach, which might as well be an integer
> or
> > short.
>
> I think only one queue where you can put messages directly on the front is
> enough. The more priorities you have, the more overhead it adds.
>
> Seriously, why should 4 be distinct from 2? First, they both should be rare
> enough that it won't make a difference in which order you execute them. And
> second: what 2 makes the thread do (stopping writing a file) you must do it
> for 4 anyway, so it's not like you're really wasting time by handling 2
> before 4.
>
> And 3 should be handled by setting a maximum capacity for queues. Even if
> you needed a message for that, you could just make it a priority message
> too. Stopping sending messages should be pretty quick to handle.
>
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>

Yes, as you point out, each of the non-lowest priority messages are easy to
handle quickly in this particular example.  But it's easy to construct
examples where more than 2 are a good idea, you need only assume that a
non-lowest-priority message could be a common case or take a longer time to
handle.

For example, certain deadlock patterns arise from using a query/response
idioms.  The deadlock can be avoided by making some kinds of messages act
with higher priority than others.

But it's fine with me to wait until more experience accrues before solving
this -- maybe there is a better way to solve the query/response
question than message priorities.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100125/cc70158b/attachment.htm>