About good practice: Should protected objects be small?

About good practice: Should protected objects be small?

[reinert]

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.

reinert

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

[Niklas Holsti]

On 17-10-20 17:50 , 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.

Protected operations limit concurrency, which (in some cases) can limit 
the performance of multi-tasking programs.

I aim to keep the worst-case execution time (WCET) of protected 
subprograms as small as possible. However, what is "small enough" is 
application-specific.

In some cases, the data structures and subprograms that need protection 
(i.e. need mutually exclusive access) are naturally largish, and 
reducing the WCET of the subprograms would be possible only by 
significant complication of the data structures and calling sequences. 
If the natural structures are fast enough, the extra complication is not 
worth it.

If your concern is the size of a protected object in terms of the number 
of source lines of code, do remember that you can call out from a 
protected subprogram to ordinary subprograms, which can be separate. Of 
course you must then pass the protected private data as parameters to 
those subprograms. (Sometimes unit-testing tools force this kind of 
structure anyway, becase the private parts of a PO may not be visible to 
the tool.)

For me, the source-code size of a protected object is not a special 
worry, no more than the size of a package or a subprogram -- ordinary 
principles of readability, modularity, etc. apply.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Dmitry A. Kazakov]

On 2017-10-20 20:27, Niklas Holsti wrote:
> On 17-10-20 17:50 , 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.
> 
> Protected operations limit concurrency, which (in some cases) can limit 
> the performance of multi-tasking programs.
 >
> I aim to keep the worst-case execution time (WCET) of protected 
> subprograms as small as possible. However, what is "small enough" is 
> application-specific.

Think of a protected operation as logically instant for the application. 
If the application response time is N then any protected operation must 
be a fraction of N. As a rule of thumb consider:

- no loops
- no copying of arrays (e.g. Strings)
- no dynamic memory allocation (e.g. Unbounded_String)
- no system calls
- no GUI calls (it is a bounded error most likely)
- no I/O (which is bounded error certainly).

[ Under GNAT you can use Text_IO for debugging purposes, but not in the 
production code ]

> In some cases, the data structures and subprograms that need protection 
> (i.e. need mutually exclusive access) are naturally largish, and 
> reducing the WCET of the subprograms would be possible only by 
> significant complication of the data structures and calling sequences. 
> If the natural structures are fast enough, the extra complication is not 
> worth it.
> 
> If your concern is the size of a protected object in terms of the number 
> of source lines of code, do remember that you can call out from a 
> protected subprogram to ordinary subprograms, which can be separate. Of 
> course you must then pass the protected private data as parameters to 
> those subprograms. (Sometimes unit-testing tools force this kind of 
> structure anyway, becase the private parts of a PO may not be visible to 
> the tool.)
> 
> For me, the source-code size of a protected object is not a special 
> worry, no more than the size of a package or a subprogram -- ordinary 
> principles of readability, modularity, etc. apply.

An addition regarding the number of entries. A call to a protected 
procedure or an entry may flip some barriers. The implementation would 
possibly walk the entries list in order to re-evaluate the barriers and 
look if a task is queued to that entry. Alternatively it can first peek 
the queue and then re-evaluate the barrier if there is a task waiting. 
In any case the number of entries could influence performance.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[reinert]

On Friday, October 20, 2017 at 8:27:41 PM UTC+2, Niklas Holsti wrote:
> On 17-10-20 17:50 , reinert wrote:
> > I am testing out using protected objects.
...snip...
> 
> If your concern is the size of a protected object in terms of the number 
> of source lines of code, do remember that you can call out from a 
> protected subprogram to ordinary subprograms, which can be separate. Of 
> course you must then pass the protected private data as parameters to 
> those subprograms. (Sometimes unit-testing tools force this kind of 
> structure anyway, becase the private parts of a PO may not be visible to 
> the tool.)
> 

OK, this is what I did (to avoid a more than 2000 lines protected object body).
However, I would like a stub ("is separate"). Why they did not allow this in a protected object? I thought the reason was that protected objects should be "small" for some good reasons (at least in terms of number of statements).

reinert




> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

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

[Robert Eachus]

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 lines on the actual hardware.  Compilers do this by allocating the storage for any protected object on a cache line boundary.  But that is not guaranteed. Worse, the compiler might be generating x86 code and have no idea what the actual cache line size is.  It is always possible to add Junk, usually under that name ;-), so that each protected value takes one cache line.  (Usually 64, 128, or 256 bytes, you can determine it at run-time.*)  Getting the beginning of the value cache boundary aligned can be done by aligning the protected record even if some of the data is never accessed.

If you want to get really fancy, you can use non-temporal loads and stores to avoid loading and saving the entire cache line. I don't know if any Ada compilers do that for protected objects, and doing it yourself is a bad idea on large projects.

* I have a function that does that for x86 will post if asked. It assumes that if the CPUID instruction does not support this, just return 64, which is usually right for very old x86 CPUs.

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

[Niklas Holsti]

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

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

[Robert Eachus]

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.