svehla@zeus.unomaha.edu (12/09/90)
Greetings Fellow Mach Enthusiasts! Can anyone tell me if there is any work being done to design and implement an Ada based Threads package similiar to the C threads? I am considering doing just that and wondered if anyone has already taken the lead. I am also considering taking the Ada based threads and implementing some higher level object oriented IPC constructs. Any info would be greatly appreciated! Please have a safe and Happy Holiday! Happy Computing Ernie Svehla
fkittred@bbn.com (Fletcher Kittredge) (12/10/90)
In article <5450.276138f0@zeus.unomaha.edu> svehla@zeus.unomaha.edu writes: > >Can anyone tell me if there is any work being done to design and implement an >Ada based Threads package similiar to the C threads? I am considering doing >just that and wondered if anyone has already taken the lead. I strongly suspect that any work you do in this area will be very quickly superseded by POSIX 1003.4a. This standard should provide a language independant threads standard for all Unix/Mach implementations. Ada is a specific target language. A implementation of POSIX 1003.4a-Draft 4 is included with OSF/1, though I don't think an Ada binding is. My guess is that hardware vendors will start shipping real OSF/1 around a year from now. Software developers probably should be able to get it in the early spring. regards, fletcher Fletcher E. Kittredge Senior Engineer Platforms and Tools Group BBN Software Products Company 10 Fawcett St. Cambridge, MA. 02138 617-873-3465 fkittred@bbn.com or fkittred@endor.harvard.edu
emery@linus.mitre.org (David Emery) (12/10/90)
>From: fkittred@bbn.com (Fletcher Kittredge) >I strongly suspect that any work you do in this area will be very quickly >superseded by POSIX 1003.4a. This standard should provide a language >independant threads standard for all Unix/Mach implementations. Ada is >a specific target language. The P1003.4a group is primarily concerned with a C interface to threads. Their work on a language-independent definition for threads is on the back burner. Furthermore, they are working with several competing threads/lightweight process models, including Ada tasking. The Ada-literate people tracking the P1003.4a work have expressed some concerns/problems with implementing Ada tasks using the current P1003.4a threads definition. No langauge other than C is "a specific target language", unless and until someone accepts the task to do the work. Right now the P1003.5 Ada Bindings group is looking for people to start work on an Ada binding for P1003.4a. If you're interested, contact Steve Deller, P1003.5 chair (deller@verdix.com) or Ted Baker (baker@alpha.cs.fsu.edu). dave emery
daveb@ingres.com (When a problem comes along . . . you must whip it) (12/18/90)
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. So while there may or may not be a Posix threads standard in the next year or two, don't count on there being an Ada binding or an Ada runtime written using pthreads. If you wanted to write an Ada binding, I'm sure there are people on the pthreads@osf.org mailing list that would be interested and willing to critique it, if not offer it as a strawman to the Posix committees for consideration. cheers, -dB In article <61465@bbn.BBN.COM> fkittred@spca.bbn.com (Fletcher Kittredge) writes: >In article <5450.276138f0@zeus.unomaha.edu> svehla@zeus.unomaha.edu writes: >> >>Can anyone tell me if there is any work being done to design and implement an >>Ada based Threads package similiar to the C threads? I am considering doing >>just that and wondered if anyone has already taken the lead. > >I strongly suspect that any work you do in this area will be very quickly >superseded by POSIX 1003.4a. This standard should provide a language >independant threads standard for all Unix/Mach implementations. Ada is >a specific target language. > >A implementation of POSIX 1003.4a-Draft 4 is included with OSF/1, though >I don't think an Ada binding is. My guess is that hardware vendors will >start shipping real OSF/1 around a year from now. Software developers >probably should be able to get it in the early spring. > >regards, >fletcher > > >Fletcher E. Kittredge >Senior Engineer >Platforms and Tools Group >BBN Software Products Company >10 Fawcett St. >Cambridge, MA. 02138 >617-873-3465 >fkittred@bbn.com or fkittred@endor.harvard.edu -- "If it were easy to understand, we wouldn't call it 'code'" David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb@ingres.com
emery@linus.mitre.org (David Emery) (12/19/90)
>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