Re: Teaching new tricks to an old dog (C++ -->Ada)

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 03/09/05 

Date: Wed, 9 Mar 2005 10:00:12 +0100

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