Re: Advantages

[Marin David Condic <nobody@noplace.com>]

Thats a reasonably good example. I'd note two things - 1) It only gets 
worse when you're interacting with other hardware or multiple processors 
and 2) Ada can't really help you when you're implementing the low level 
primitives that Ada uses to accomplish things like the semaphores you 
describe.

In case #1, you're dealing with a certain amount of asynchronicity and 
concurrency with what the hardware is doing and that is just simply 
beyond the scope of what Ada can address. In case #2, one hopes that if 
you get a good, solid model for handling all the primitive operations 
Ada needs, then the things you build upon it will be solid as well. In 
this way, Ada is a help. But you *still* have to get those low level 
primitives right and any errors in logic at that level will create 
instability in the OS.

That's why I say that getting a secure and reliable OS built is a 
difficult task and that Ada is no guarantee of success in that arena. 
All the primitives needed to do semaphores, rendesvous and multitasking 
in general are *complicated* and hard to get right. Ada doesn't help 
here because it must rely on those mechanisms being right before it can 
exist.

MDC


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.
> 
> In most programming languages, including C for example, under a typical
> execution environment or OS, the usual or only way to do this will be by the
> explicit use of semaphores (or a similar facility). When a thread wants to
> read or update the variable, it sets the semaphore (which may cause it to
> wait (to be 'blocked')). When it has finished, it resets the semaphore
> (which may unblock another waiting thread). Let's say the function to set a
> semaphore is named 'sem_p', and the function to reset it is 'sem_v'. If the
> variable is named 'r' (and has members 'x' and 'y') and the semaphore is
> named 's', a C program might contain code like this:
> 
>    /* Thread A */
>    ...
>    sem_p(s); /* set the semaphore, maybe wait */
>    x = r.x; y = r.y; /* read the variable */
>    sem_v(s); /* reset the semaphore */
>    ...
> 
>    /* Thread B */
>    ...
>    sem_p(s); /* set the semaphore, maybe wait */
>    r.x = x; r.y = y; /* update the variable */
>    sem_v(s); /* reset the semaphore */
>    ...
> 
> This is all well and dandy, but there are many things that can go wrong. For
> example, supposing a programmer accidentally omitted one of the calls to
> sem_p or sem_v? Or accidentally used the wrong semaphore in one of the
> calls? This kind of mistake is easily done in a big, complex program with
> lots of threads and semaphores. The consequences are often hard to debug: it
> is typical that a problem is only manifested intermittently; it is typical
> that using a debugger (single stepping or breakpoint jumping) destroys the
> temporal circumstances of normal execution that are needed to observe the
> problem at all; it is typical that, even when the problem is observed, the
> cause is subtle and very hard to determine.
> 
> In Ada 95, you would typically use a protected object to protect the
> variable from unwanted parallel access. (In Ada 83 you would typically have
> used a task and a 'rendezvous', but I'll illustrate the protected object
> approach here.)
> 
>    type R_Type is
>       record
>          X, Y: Float;
>          ...
>       end record;
> 
>    protected Prot_R is
>       function Get return R_Type;
>       procedure Set (New_R: in R_Type);
>    private
>       Inner_R: R_Type;
>    end;
> 
>    protected body Prot_R is
> 
>       function Get return R_Type is
>       begin
>          return Inner_R;
>       end;
> 
>       procedure Set (New_R: in R_Type) is
>       begin
>          Inner_R := New_R;
>       end;
> 
>    end Prot_R;
> 
>    ...
>    --- in task A
>    declare
>       Local_R: R_Type;
>    begin
>       Local_R := Prot_R.Get; -- read variable
>       X := Local_R.X;
>       Y := Local_R.Y;
> 
> 
>    ...
>    --- in task B
>    Prot_R.Set((X,Y,...)); -- update variable
> 
> Because the use of OS primitives such as semaphores is hidden from the user
> by Ada, many of the mistakes that would be easy to make in the C code are
> either impossible -- for example, we cannot omit a call to set or reset a
> semaphore, since Ada does these for us invisibly -- or caught by the
> compiler and reported to us in an obvious way -- for example, if we tried to
> use 'Inner_R' in an expression in task A or B, the compiler would complain
> that Inner_R is not visible at that point (because it is private to Prot_R).
> 
> Obviously this example is simplistic compared to real software, but I hope
> it gives a flavour of Ada's advantages in concurrent programming.
> 
> You might like to note that the use of an Ada protected object gives further
> advantages than I have mentioned so far. It is implemented in such a way
> that functions are permitted to be parallel with one another (but not with
> any procedure). So, tasks A and B would be permitted to read Prot_R
> simultaneously, but no task would be allowed to read it while another was in
> the middle of setting it. Protected objects can provide yet more
> sophisticated functionality (with 'entries'). And then there are tasks,
> rendezvouses, and various other facilities too. All of this functionality
> can be achieved in other languages, but generally only at a lower and more
> error-prone level.
> 
> Really, one could write a big book about concurrent programming in Ada.
> Hehe, in fact I'm sure somebody has! I'm sorry, I can't recall the details,
> but I'm sure someone else will oblige.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================