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 10.107.136.15 with SMTP id k15mr4379581iod.29.1463001611545; Wed, 11 May 2016 14:20:11 -0700 (PDT) X-Received: by 10.157.37.168 with SMTP id q37mr82091ota.1.1463001611473; Wed, 11 May 2016 14:20:11 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i5no7729202ige.0!news-out.google.com!z2ni597itc.0!nntp.google.com!i5no7729193ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 May 2016 14:20:10 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8202:8510:a0e0:f5f4:a488:12f4; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8202:8510:a0e0:f5f4:a488:12f4 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <04dcee71-200c-4f05-9e34-3ecc38bf1d7c@googlegroups.com> Subject: Re: Two-stage suspend operations From: rieachus@comcast.net Injection-Date: Wed, 11 May 2016 21:20:11 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30385 Date: 2016-05-11T14:20:10-07:00 List-Id: On Saturday, May 7, 2016 at 12:13:19 PM UTC-4, Simon Wright wrote: > >It turns out that the 20 kHz is in a separate processor from the main=20 >application.=20 >Nothing like an enthuse-potential-volunteers description of a project=20 >for generating confusion. Good, fifty microseconds is not a lot of time with a full tasking system. >> Note BTW, that the GNAT pragma specifically allows the protected=20 >> objects that only run in the context of another task/thread, have a=20 >> high enough priority not to be interrupted, and do not reference any=20 >> lower priority protected objects.=20 > Can you tell me where this is documented? It really isn't. You have to know how you expect a particular PO to map to = say the RMW instructions provided by your particular hardware. If it does?= Fine. If not you have work to do to figure out what is confusing the com= piler, or where you are confused. When someone goes to port the software to new hardware? It may work "right= out of the box", or they may need to find what the equivalent primitive is= for the new hardware and how to get the compiler to see it their way. )-:= =20 > Also, there seems very little difference between using Lock_Free and=20 > Atomic: you can't have entries, and, when 'Contents' is an array of=20 > integers,=20 > lock_free.adb:3:07: illegal body when Lock_Free given=20 > lock_free.adb:3:58: type of "Contents" must support atomic operations I know the issue of an array of integers not supporting atomic updates was = discussed in the ARG, but I don't believe it was ever "fixed." To map the = issue from theory to actual hardware, there is no guarantee that integers (= of whatever size) can be updated atomically without affecting adjacent arra= y entries. Hmmm. Try: type Foo is aliased limited new Integer -- is that the right order? Bar: array (Integer range 1..10) of Foo; Better may be an array of protected integers? =20 > Only mono-processor at the moment. In computer science almost everything used three numbers, zero, one, and ma= ny. In this area the numbers are zero, one, and many. It is difficult to = generate a deadlock that requires two processors, but livelock situations a= re often dual-processor related, and starvation can easily occur with many = processors. > I didn't mention that we are using Ravenscar, I thought that precluded=20 > deadlock? One of those good news bad news things. Ravenscar can show that your main = program is deadlock free--as long as you make promises about the non-Ada co= de in things like device drivers and the OS. Choosing the right OS or impl= ementing on bare metal takes care of 99% of that. But gotchas can turn up a= nywhere. For example a processor with microcode that was back-patching mis= sing instructions so that they only caused interrupts once. Finding the ri= ght set of compiler directives fixed that, but of course, the hardware docu= mentation had no clue...