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: dennison@telepath.com Subject: Re: Ada vs C++ vs Java Date: 1999/01/15 Message-ID: <77nv90$jul$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 433005951 References: <369C1F31.AE5AF7EF@concentric.net> <369D1F2B.138D1FB8@pwfl.com> <369E4A41.8D7DDA14@west.raytheon.com> X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Fri Jan 15 17:52:37 1999 GMT Newsgroups: comp.lang.ada,comp.lang.c++,comp.vxworks,comp.lang.java X-Http-User-Agent: Mozilla/4.5 [en] (WinNT; I) Date: 1999-01-15T00:00:00+00:00 List-Id: In article <369E4A41.8D7DDA14@west.raytheon.com>, Ken Keys wrote: > Have you (or do you have first hand knowledge of anyone who has) ever > used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or > do you, like everyone I have ever met, use the OS services (semaphores > etc.) directly? Right here. Our first crack at a scheduler here did just that. If you think about it, in a good RTOS a rendezvous can be supported almost entirely via the RTOS' tasking exec and mutual-exclusion mechanisms. On VxWorks that means a semaphore. However, with Ada95 you don't actually need rendezvous to achieve mutual exclusion or perform real-time task scheduling. The "delay until" statement allows tasks to be scheduled at a specific rate by the RTOS itself. And of course the language allows you to set task priorities (in a portable manner too). Using those two facts, one can acutally create a RMT real-time application that will run on *any* RMT-supporting RTOS with just a recompile. The only non-portable scheduling code we have is the call that sets the clock rate (VxWorks' default of 60Hz wasn't fast enough for us). Simple (or evey fairly complicated) mutual exclusion can be more efficiently accomplished w/ protected objects than rendezvous. Thus there really isn't much call for rendezvous anymore, unless you want the data-passing client/server interaction they provide. Use the OS directly? Yuk. Then you'd loose the portability. That's sort of like optimizing; You shouldn't bother unless you are known to be operating too slowly, and the changes *will* solve that problem. > Java has threads. In C++ it is more of a library issue. The C++ standard > doesn't address it but Posix does. The RTOS probably includes a Posix > library and if it doesn't, it probably doesn't support Ada either. That's fine, if you can live with being tied to POSIX RTOS's. But why tie yourself down when you don't have to? T.E.D. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own