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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: About good practice: Should protected objects be small? Date: Mon, 6 Nov 2017 10:27:10 +0200 Organization: Tidorum Ltd Message-ID: References: <5b65b9f0-25d9-449a-b7eb-d1fc112f293f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net HOT12R/ACbvKOLOdsjnQEwkQ39aZEO7Cqq8uaU0JItQ2RDJYDR Cancel-Lock: sha1:kaYH8wWpbWclYiABVr2i7KEv1a4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:48728 Date: 2017-11-06T10:27:10+02:00 List-Id: On 17-11-06 07:41 , Robert Eachus wrote: > On Friday, October 20, 2017 at 10:50:44 AM UTC-4, reinert wrote: >> I am testing out using protected objects. >> >> Is it reasonable good practice to keep protected objects small? It >> seems like for me (?) and stubs ("is separate") is not allowed >> there. > > Not really the question asked, but it can jump up and bite you. You > really want the size of the protected object to be a multiple of hash (That was meant to be "cache", not "hash", I think.) > lines on the actual hardware. In the context of this thread (protected object principles and practices), I feel called to comment on Robert's advice. I am ready to believe that Robert's advice is very sound when the goal is to maximise performance of frequently accessed protected objects in a multi-core system, where the Ada tasks are running in parallel on different cores. Core-to-core communication about the ownership of data-cache lines, and the movement of data-cache lines between per-core caches, for the purpose of keeping the per-core data caches coherent, can have a large effect on execution speed, AIUI. However, that concern, and Robert's advice, is about the *data* (variables) in the protected object, while the original question AIUI was perhaps more about the size of the *code* of the protected operations, and the fact that they cannot be made separate, as such. I don't think there is any need to consider *code* cache-line size when designing a protected object. Cores usually have separate (Harvard-style) Instruction and Data caches, and the I-cache is usually read-only and does not need coherence management, unlike the D-cache. However, I am rather ignorant about the cache architetures of x86-based systems, never having used such a system in a real-time application. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .