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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: f5d71,d275ffeffdf83655 X-Google-Attributes: gidf5d71,public X-Google-Thread: 109fba,d275ffeffdf83655 X-Google-Attributes: gid109fba,public From: robert_dewar@my-dejanews.com Subject: Re: Ada vs C++ vs Java Date: 1999/02/09 Message-ID: <79pdd1$3mj$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 442364456 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> <8p64spq5lo5.fsf@Eng.Sun.COM> <77t3ld$nou$1@nnrp1.dejanews.com> <79ce4s$lfq$1@nnrp1.dejanews.com> <79chc7$ko6@drn.newsguy.com> <79dodb$rhf$1@nnrp1.dejanews.com> <79jeos$bu4@bgtnsc01.worldnet.att.net> <79k65l$s0t@drn.newsguy.com> X-Http-Proxy: 1.0 x4.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Feb 09 13:32:17 1999 GMT Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-02-09T00:00:00+00:00 List-Id: mike writes: > I does not matter. pthreads is standard, calling it from > your program is not much different from using a language > build-in task. you simply add pthreads library to you > Makefile and that is it. It is no big deal. Actually the big deal is precisely the above attitude. It is of course totally false that it is no big deal to go to the use of pthreads. Making programs thread safe is not at all easy (and indeed the C and C++ language, by not providing nested subprograms make this technically difficult). In addition, the semantics of basic C constructs is not well defined in the presence of threading. The interaction of threading with language semantics is very tricky. The Ada design gave a lot of careful thought to it, the C and C++ design was of course pretty much oblivious to this (you cannot get any hint for example of whether standard functions mentioned in the ANSI C standard are required to be thread safe, because the issue was simply not considered). As for pthreads being a standard: only someone not very familiar with pthreads would make this casual statement with the implication that there are no portability issues. In fact critical semantics in pthreads is (quite deliberately) left implementation defined, at least partly as a result of failing to agree on specific requirements. The threading in Ada is FAR more tightly defined, and in fact as a result it is simply not possible to map Ada threading into pthreads (because the pthreads standard leaves too much undefined). GNAT is for sure implemented over a pthreads layer on most machines, but we have to provide specialized interfaces to each different pthreads implementation to deal with idiosyncrasies of that particular implementation. When you are using Ada, the Ada runtime has taken care of these variations. When you write in C or C++, the application has to deal with these variations if it wants to be portable. So how come in practice people can successfully write C applications using pthreads? In a lot of cases, the code is simply not portable. People experiment and find out what works on a given operating system. Most people using pthreads have not even read the pthread standard, let alone carefully absorbed all the technical details so that they know what needs to be done to write fully portable code, and as a result much pthreads code written in C is simply not portable. When we work with customers trying to port Ada applications from one system to another, we find that if people have stuck to the standard Ada tasking semantics, then porting can be relatively straight forward. If they have used implementation dependent thread stuff directly, the code is often very difficult to port. Of course, as usual Ada is not a guarantee of doing things right, but it often encourages people to write portable code. In this particular case, it is quite easy to write completely portable multi-threaded code using Ada, without needing any knowledge at all of the underlying operating system or its particular implementation of pthreads. I must say it is a big disappointment to us as Ada implementors that the pthreads world is such a mess. We had hoped that standardization of pthreads would make it as easy to move our tasking implementation from one system to another as it is to move our I/O implementation, but this is far from the case. Just have a look at the GNAT sources to see how much target dependent code is required in the tasking runtime to deal with idiosyncrasies of various systems. Of course an Ada *programmer* as opposed to an Ada *implementor* does not have to worry about this, but you have no such distinction in the C world! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own