From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Thu, 1 Oct 2020 20:01:45 +0300 Organization: Tidorum Ltd Message-ID: References: <00cd3aaa-d518-43a2-b321-58d6fae70aebo@googlegroups.com> <57eb7a65-51ea-4624-b9dc-9c4dda0fee59n@googlegroups.com> <5f70fd3b$0$13541$426a74cc@news.free.fr> <87wo0d3iac.fsf@nightsong.com> <87sgb02l7b.fsf@nightsong.com> <875z7vyy1u.fsf@nightsong.com> <87wo0bkns3.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net MGTvYAeQXsWClwVtF2NW6gmzqi0j+YxpJ1vdchGOQTeJpjhm5h Cancel-Lock: sha1:r1xaGTMuc/N+ohw8ZkXWcMXjNjA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:60368 List-Id: On 2020-10-01 19:06, Dmitry A. Kazakov wrote: > On 01/10/2020 17:38, Niklas Holsti wrote: > >> If the protected procedures belong to different protected objects, yes >> it is legal. But not if they belong to the same object, as J-P noted. > > But then you have a problem when two independently running protected > procedures of *different* objects call a procedure of a third object. > You must serialize these calls, and that is effectively blocking. I don't know what you mean by "effectively", here, but yes, one of the tasks must wait for the other task to complete the protected operation on the third object. So what? This is the idea of a protected object: if two tasks want to operate on the same object at the same time, the tasks must be serialized, and one task must wait for the other. This applies even if the task that has to wait is already in the middle of another protected operation on another object. This is analogous to the fact that any task may have to wait for higher-priority (possibly pre-empting) tasks to finish their current work, and in fact the ceiling-priority-locking method uses this fact to implement the protection of protected objects. Even a task that is in the middle of a protected operation can be pre-empted by a higher-priority task and so may have to wait, as is normal in priority scheduling. While the usual advice is that protected operations should be "short and quick", this is as misleading as claiming that a real-time program must react "quickly" to inputs. In a given real-time program, the actual upper limit on the duration of a protected operation is set only by the effect of that operation's execution on the overall schedulability of that program. At low priorities, where deadlines usually are relatively long, it is quite ok to have protected operations that take quite a while to execute, as long as the overall response times of the affected low-priority tasks remains shorter than their deadlines. Of course the same principle applies at all priority levels.