Re: Advantages

["Robert I. Eachus" <rieachus@comcast.net>]

Nick Roberts wrote:
> "Andrew Carroll" <andrew@carroll-tech.net> wrote in message
> news:mailman.165.1088318818.391.comp.lang.ada@ada-france.org...
> 
>>... What features of Ada make it easier to detect pitfalls
>>in parallel programming?  What features of Ada help with
>>debugging?
> 
> 
> I don't wish to cross with Marin in answering this, but forgive me if I
> throw my oar in a bit.
> 
> Suppose I have two threads (another name for 'tasks') which both need to
> read a variable (which is a struct (record)) from time to time, and one of
> them also updates the variable from time to time. When an update is done, it
> involves assigning values to several of the variable's members (components),
> so the update is not 'atomic'. This means that there needs to be some kind
> of synchronisation between the threads, to prevent one thread trying to read
> the variable right in the middle of it being updated.

Nick's example is a good one, but it misses a part of the flavor of why 
it is such a huge advantage.  If you know you are going to have to 
protect some object, you declare it as a protected object (makes sense 
;-) with a Get function and a Set procedure.  As the design and software 
development process proceeds, you may have to change the management of R 
dozens of times.  But all these changes are local to the protected 
object that implements R.

If as often happens in a system design, you need to hold two or more 
locks at once, you need to prevent the possibility deadlock.  (Or you 
should prevent the possibility of deadlock.)  One way to do this is to 
show that there is an ordering of all of the semaphores such that no 
task holds a higher numbered semaphore when it acquires a lower numbered 
semaphore.

In Ada, if all these semaphores are actually internal to protected 
objects, the only way to hold R while acquiring S is for the protected 
object for R to have a call which internally calls the protected object 
for S.  This is not hard to write in Ada, but the implicit ordering of 
with clauses will make it impossible for you to have a call that gets S 
while holding R, another call that gets T while holding S, and a third 
call that gets R while holding T.  For that matter any matter any 
calling sequence that violates the rule will mean that the compiler will 
reject the program.  So you can design, build and maintain complex 
real-time systems with many threads of control in Ada, and not only will 
there be no deadlocks, you won't have to do lots of analysis to show 
that the software is deadlock free.  (Yes, you can put two protected 
objects in the same scope and violate the implicit ordering.  But now 
the only source of potential deadlocks is in that one unit--that I hope 
violates your software development plan in some way.)

-- 

                                           Robert I. Eachus

"Reason and experience both forbid us to expect that national morality 
can prevail in exclusion of religious principles." -- George Washington