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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-06 12:40:29 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: jimmaureenrogers@worldnet.att.net (Jim Rogers) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? Date: 6 May 2003 12:40:28 -0700 Organization: http://groups.google.com/ Message-ID: <82347202.0305061140.53347ae1@posting.google.com> References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0304240446.493ca906@posting.google.com> <3EA7E0E3.8020407@crs4.it> <9fa75d42.0304240950.45114a39@posting.google.com> <4a885870.0304291909.300765f@posting.google.com> <416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net> NNTP-Posting-Host: 209.194.156.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1052250029 25176 127.0.0.1 (6 May 2003 19:40:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 6 May 2003 19:40:29 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63225 comp.object:62841 comp.lang.ada:37013 misc.misc:13976 Date: 2003-05-06T19:40:29+00:00 List-Id: Hyman Rosen wrote in message news:... > Georg Bauhaus wrote: > > Answer: There is no trace of "distribution", not even of concurrency, > > in C. I wonder how that distinct feature of Ada vs C can be > > discarded, economically. > > Because people have in fact written multithreaded and distributed > programs in C and in C++, so it's not exactly a mystery how to do > it. Furthermore, that Ada 95 had to come up with a new concurrency > mechanism (protected objects) is evidence that people were unhappy > with the facilities available in Ada 83, at least for some uses. > One could then make an argument against Ada by asking whether it > is certain that Ada got it right this time. And people have made pictures by glueing colored stones to a background. This does not make the use of C or C++ either a best technical choice or a best economical choice for multithreaded designs. In fact there were some problems with the original Ada design for task communication. Under certain conditions the rendezvous mechanism encountered race conditions. This problem was fixed in Ada 95. Additionally, the protected object mechanism was added. Note that C and C++ concurrency must be explicitly based upon multiprocessing or multithreading. The Ada model is not so explicit. Operating systems supporting threading are relatively new compared to the languages C, C++, and Ada. Most commercial operating systems prior to 1994 provided no support for what is now called threads. Ada compilers would implement concurrency using multiple processes. Currently many commercial operating systems support some flavor of threads. The same Ada code can be recompiled with a current compiler targeted at a modern operating system. It would then use threads instead of processes. C and C++ provide no comperable source code portability across operating system generations. It turns out that the Ada protected object is both highly reliable and highly efficient. The relatively high level of design abstraction allowed by Ada protected objects results in correct, efficient code much faster than can be achieved using the low level threading libraries available to C and C++. One of the areas of particular difficulty using C and C++ thrading libraries is dealing with operating system interrupts. The general consenus in comp.programming.threads is that one should avoid mixing interrupts and threads using C or C++. Ada 95 provides a very clean interrupt handling model that takes advantage of concurrency and tasking. This is possible because the solution is part of the language syntax, not simply an external library. The compiler can actually understand what you are creating and provide the correct level of optimization and isolation. Compare the Ada protected object to the Java monitor. Both are supposed to be used for the same purposes. The Java monitor employs a lower level of abstraction. It also provides a less efficient and less deterministic implementation. By comparison Ada got it right and Java got it wrong. Even worse, Java has deprecated some of its Thread class methods because they have been found to create deadlocks. Java is not even in the position to correct the problem. It now expects the programmer to develop a correct way to stop a thread without specific help from the language. The rules about creating Java monitors result in awful violations of class coupling and encapsulation rules. In this manner Java threads are bad citizens within Java itself. Jim Rogers