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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <157t6st03yru3.124h9wuwhw9si$.dlg@40tude.net> <112sp515nirmhea@corp.supernews.com> Date: Wed, 9 Mar 2005 10:00:12 +0100 Message-ID: NNTP-Posting-Date: 09 Mar 2005 09:56:58 MET NNTP-Posting-Host: 49949037.newsread2.arcor-online.net X-Trace: DXC=M>?IQnig;`VgQ;OFXR3=FUQ5U85hF6f;TjW\KbG]kaMX]kI_X=5KeaV@WLLO>ILfT_WRXZ37ga[7Zn919Q4_`VjYB8=X\UUgbkT X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8913 comp.lang.c++:44720 comp.realtime:1105 comp.software-eng:4665 Date: 2005-03-09T09:56:58+01:00 List-Id: On Tue, 08 Mar 2005 21:51:00 -0500, CTips wrote: > Umm...can be done without locking. See wait-free/lock-free algorithms. Honestly, I don't care. You know, I am not developing integer incrementers, am developing software... >> Therefore spinning for a lock (which probably would be the >> implementation) will likely be less expensive than some tricky guards >> attached to each and every instruction. > > You *REALLY* should see what can be done with lwlock/stwcond. You'll be > suprised how cheap synchronization can be. > >> Note also that at such a low level >> it would be very difficult if possible to maintain data consistency. >> Compiler simply does not know what is related to what and will try to cope >> with the worst case scenario. > > So, what escapes does the language provide to let you do this? None? As I said it provides protected objects, which in a real-life concurrent application will be more efficient, far more safe and maintainable, and yet portable as compared with your inlined assembler in C. I saw much too much of embedded C code programmed in the style you seem to favor. The main problem with such code, is that it's a garbage which simply does not fulfill the requirements, including the time constraints as well. BTW, if you are so eager to have assembly code insertions, then Ada does have them. See ARM 13.8. >> Protected types in Ada are to describe this >> sort of semantics. So in the end atomic integers are pretty useless, no >> matter how efficient they could be implemented. > > That is one reason *NOT* to learn Ada; it restricts both choices and > thinking. How does Ada restrict choices? As for thinking that's up to you. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de