Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!agate!linus!linus!emery From: emery@linus.mitre.org (David Emery) Newsgroups: comp.os.mach Subject: Re: Ada Threads? Any work out there? Message-ID: Date: 19 Dec 90 14:47:11 GMT References: <5450.276138f0@zeus.unomaha.edu> <61465@bbn.BBN.COM> <1990Dec18.062202.24384@ingres.Ingres.COM> Sender: usenet@linus.mitre.org Organization: The Mitre Corporation, Bedford, MA Lines: 50 In-reply-to: daveb@ingres.com's message of 18 Dec 90 06:22:02 GMT >From: daveb@ingres.com >The Ada community seems to be at war, both internally and externally >over the issue of Posix threads. One camp says that threads are a bad >idea, and that Ada tasks are the only thing that should exist; >therefore, there should be no binding of Posix threads to Ada. Other >camps say that Posix threads should/should not be usable as the >implementation model for Ada tasks, making it possible to write a >portable Ada runtime. The non-Ada camp in Posix would just like to have >a useable C-like standard, and feels greatly frustrated by the divisions >and dissent from the Ada crowd. Two points: 1. The major area of disagreement within those of us looking at both POSIX Threads and Ada is the degree of support required by the underlying threads model for implementing an Ada runtime system. The major goal (of both sides of the issue) is to come up with a unified model so that POSIX (C) threads and Ada tasks are the same thing, at least as far as scheduling is concerned. In either case, an Ada binding to POSIX threads must provide reasonable access to the POSIX threads facilities, either by establishing an equivalence with existing Ada facilities (e.g. thread = task) or by providing new interfaces. I have not heard anyone involved with POSIX from the Ada community argue that an Ada binding to POSIX threads is a bad idea. However, there are many ways to skin the cat, and I'm sure we'll be in for some interesting discussions when the Ada binding work starts in earnest. If the goal is portable Ada runtime systems, then this places additional requirements on the POSIX threads model, to provide those facilities needed by Ada task semantics. This is the goal of some of the Ada people involved with the current IEEE P1003.4 effort. I have a lot of sympathy for this goal, as it brings some significant cost savings, etc, to Ada runtime systems, but I personally am not convinced that it should be a "requirement" on POSIX threads, while "peaceful and cooperative coexistance of threads and tasks" is clearly a requirement on the aggregation of POSIX Threads and the Ada binding. 2. From my personal perspective, the majority of the POSIX Threads group is not constrained by the (fairly low-level) debate within the Ada community. The major problems in POSIX threads seems to me to be the fact that there are many existing (C-based) threads packages out there, and proponents of each are unwilling to compromise in such a way that would cause major damage to their current implementation. Although I can have a certain degree of sympathy with an unwillingness to change something that works, one thing you have to remember about standards is that more than half of "standard" has to do with taking a "stand". dave emery