Re: About good practice: Should protected objects be small?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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
       .      @       .