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

[Robert Eachus <rieachus@comcast.net>]

On Monday, November 6, 2017 at 3:27:13 AM UTC-5, Niklas Holsti wrote:
> On 17-11-06 07:41 , Robert Eachus wrote:
 
> > 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.)

Yes.

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

Yes.  I have seen cases where the programmer triumphantly reduced the size of the object of a protected type, then was shocked when execution time went pear shaped.
> 
> 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.

In most x86 family chips the L1 Instruction lines start out as a multiple of the L2 cache line size, then gets extremely ugly.  The chip front-end grabs up to 32 bytes non-aligned with the cache, then tries to mark where instructions might begin.  Fortunately, unless you modify code, then do a flush, the instruction cache logic can be ignored.