From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3e3949298ed3b36 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: High CPU in tasking Date: Fri, 25 Jun 2004 18:03:19 +0100 Message-ID: <2k346nF16pckjU1@uni-berlin.de> References: <2k0fllF160eotU1@uni-berlin.de> <2k1114F15uoj8U1@uni-berlin.de> X-Trace: news.uni-berlin.de KU4vKrBCkWVvp4Y8VpSyBA1lI3zDCBr5gRvF6RfnB1mMTxUbU= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Xref: g2news1.google.com comp.lang.ada:1892 Date: 2004-06-25T18:03:19+01:00 List-Id: "Lutz Donnerhacke" 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