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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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