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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: About good practice: Should protected objects be small? Date: Fri, 20 Oct 2017 21:21:26 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <5b65b9f0-25d9-449a-b7eb-d1fc112f293f@googlegroups.com> NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:48534 Date: 2017-10-20T21:21:26+02:00 List-Id: 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