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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:6241:: with SMTP id d62mr3356963itc.18.1551452847809; Fri, 01 Mar 2019 07:07:27 -0800 (PST) X-Received: by 2002:aca:4752:: with SMTP id u79mr3382886oia.132.1551452847403; Fri, 01 Mar 2019 07:07:27 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!i2pn.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!y22no92497ita.0!news-out.google.com!v188ni245itb.0!nntp.google.com!y22no92496ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 1 Mar 2019 07:07:26 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.98.77.125; posting-account=L3mulQoAAADsXVjCD5rM6Ap3Xy0U3ckB NNTP-Posting-Host: 194.98.77.125 References: <4s8rud$9j3@tribune> <792fba1b-7a54-4d00-ae85-e6bd0737f001@googlegroups.com> <1d9e7148-cc7d-423b-9c4a-2372d1af4ddd@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6968ffe9-6fc1-4253-a3f0-14cfd474925f@googlegroups.com> Subject: Re: Why couldn't an operating system be written in ada From: fabien.chouteau@gmail.com Injection-Date: Fri, 01 Mar 2019 15:07:27 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:55744 Date: 2019-03-01T07:07:26-08:00 List-Id: I implemented the SMP support in Ravenscar. You are right in you analysis. On Wednesday, February 27, 2019 at 11:12:18 PM UTC+1, Niklas Holsti wrote: > The implementation of protected objects may have to be somewhat > different. In a single-core system, mutual exclusion can be implemented > by the "ceiling priority" method, but that doesn't work in multi-core > systems, so more conventional locks must likely be used. > We use "fair locks" to keep a constant worst case access to the protected object.