Re: High CPU in tasking

["Nick Roberts" <nick.roberts@acm.org>]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrncdnlc9.nv.lutz@taranis.iks-jena.de...

> > Would it be possible to have a separate protected object
> > container a buffer for each reader?
>
> In this case, the writer has to fill an unconstraint array of
> ringbuffers.
> ...
> Every data belongs to every reader. It's a manifolder which
> clones the whole data to many receivers.

That was one of the application details I didn't know.

> This seems much more inefficient.

Not necessarily. Again, I must make some assumptions about your application,
and the machine it is running on (specifically that it is or may be SMP),
but it is possible that the time cost of writing each packet n times rather
than once would be more than compensated for by the decrease in memory
contention of multiple readers simultaneously processing the packet.

In fact, the only way to establish which approach worked better would be to
try them both and measure their speed.

Note that the cost of contention, mainly because of the cache flushing
caused, could be very high compared to the cost of writing, which might
require just one cache flush. It's interesting to note that this is a case
where it would be useful to have compiler (or linker) support for placing
objects in memory locations that correspond to different cache 'colours'.

> > ... especially if you make the writer a higher priority than
> > all the readers.
>
> Why? This would cause the writer to overwrite the ringbuffer
> without any reading access.

Not unless your code is faulty. You must not rely upon priority or
expectations of the executional progress of tasks to replace proper
synchronisation control.

I think the priority adjustments I suggested are also invalidated by the
information you have given (above). I won't explain why I made the
suggestion, as I don't want to confuse you, but trust me that there was a
good reason.

> > I suggest the logger task should made a lower priority than all
> > the other tasks (so that it tends to work in the gaps between
> > reader and writer activity). I suggest the supervisor task be made
> > a higher priority than all the other tasks, so as to minimise any
> > delay in acting on incoming commands (such as 'stop' ;-)
>
> The whole program is event triggered. There are no free running
> code sequences. The only effect I can imagine will be a deadlock ;-)

Not unless your code is faulty. You must not rely upon priority or
expectations of the executional progress of tasks to replace proper
synchronisation control. (Hope I don't sound like a parrot :-)

If you would be willing to show the relevant code, and describe your
application's goals and design in a bit more detail, I'd be very interested.

-- 
Nick Roberts