This issue features:

The bounded buffer is a classic concurrent programming component exhibiting asynchronous task interactions. The concept is that of a buffer of a fixed size that is accessed by multiple tasks, some inserting items and some removing them, concurrently and asynchronously. Hence the buffer implementation must be protected against race conditions in which the tasks access the implementation in an interleaved manner and thereby corrupt the representation. In addition to this “mutually exclusive access”, the buffer also requires “condition synchronization”, in which callers are kept waiting until the requested buffer has the necessary state. For example, a task cannot remove an item from a buffer when the buffer is empty. Likewise, an item cannot be put into a buffer when the buffer is full.

Prior to Ada 95, programmers wanting to write portable code had to use the rendezvous to achieve mutual exclusion, with guards to implement the condition synchronization, because no other synchronization mechanism was provided by the language. Although the extended rendezvous has a number of advantages and was a step forward in language design, it has significant overhead when compared to lower-level mechanisms such as semaphores, and is a synchronous mechanism as well. (Ada 80 had a built-in “Semaphore” task type, intended to be implemented efficiently and used as the name suggests, but mixing the higher-level rendezvous with the much lower-level semaphore abstraction was considered poor language design.) In addition, the rendezvous is only available between tasks, meaning that the buffer would have to be implemented as a task too, like the accessing threads. As a result, inserting and removing items would involve expensive task switching, which is the primary source of the comparative inefficiency.

The protected type construct added in Ada 95 addresses this issue directly. Protected types provide efficient mutually exclusive access to encapsulated data, with direct expression of condition synchronization when required. Protected types do not define threads of control, so their use does not involve task switching, and although they do more than simple semaphores, their overhead is comparable.

generic
   type Element is private;
package GNAT.Bounded_Buffers is

Given this generic formal profile, users can instantiate the generic as required. For example, given an appropriate generic actual parameter type named “Job”, we could instantiate it as follows:

   package Jobs is new GNAT.Bounded_Buffers (Element => Job);

The package declaration contains a pragma Pure so that the generic can be used during library unit elaboration without a potential access-before-elaboration problem. That effect is achieved because Pure units are preelaborated, in addition to other semantics.

Next the package declares the array type used internally in the representation of the bounded buffer type:

   type Content is array (Positive range <>) of Element;

The array type must be declared outside the protected type, rather than inside in the private part as a hidden implementation artifact. This is an unfortunate holdover from the fact that protected types were originally named “protected records”, with record type semantics: record types cannot declare such things as other types! This limitation was known during the Ada 2005 revision but other revision aspects were more important, so this undesirable restriction remains.

The next declaration in the package is a constant value of type System.Priority:

   Default_Ceiling : constant System.Priority := System.Default_Priority;

In a real-time application using the Real-Time Systems Annex, protected types are given a “ceiling” priority. The constant declared here is a default for that purpose so that applications not using that Annex can ignore this aspect.

Finally the package declares the protected type itself, with two discriminants:

   protected type Bounded_Buffer
      (Capacity : Positive;
       Ceiling  : System.Priority)
   is
      pragma Priority (Ceiling);

The first discriminant is the capacity of the instance object, that is, the maximum number of values it can contain. This value will be used in the declaration of a hidden array object of type Content. With this approach, different objects of the one buffer type can have different capacities. The second discriminant represents the ceiling priority value, used in the pragma Priority. This is where the Default_Ceiling constant would be used in non-real-time applications. Note that we cannot use the Default_Ceiling constant as a default discriminant value because the language does not allow some discriminants to have defaults unless all have defaults.

Continuing with our “Jobs” example instantiation, declaration of a bounded buffer specifies these discriminant values:

   Buffer : Jobs.Bounded_Buffer (Capacity => 20,
                                 Ceiling => Jobs.Default_Ceiling);

In this example we have arbitrarily set the capacity of Buffer to 20. Note that the Bounded_Buffer type is provided directly as a protected type, rather than as a limited private type completed with a protected type. With this approach, clients have full flexibility to do all that protected types allow, such as timed and conditional calls.

Next the protected type declares the visible operations. The two primary operations are Insert and Remove, defined as entries for the sake of the barriers that specify the required condition synchronization. (Only protected entries can have barriers, unlike protected procedures and functions.) The barriers express the “not full” and “not empty” conditions and keep their callers waiting until those conditions hold.

      entry Insert (Item : Element);
      entry Remove (Item : out Element);

Then three functions are declared. The names “Empty” and “Full” describe the purpose of the first two functions. The third, “Extent”, returns the number of elements currently held in the buffer. It is worth noting that the state of a buffer to which these functions may be applied can change immediately after the call returns.

      function Empty return Boolean;
      function Full return Boolean;
      function Extent return Natural;

In part two of this Gem we will explore the private part of the protected type, the package body, and the body of the protected type.

Related Source Code

Ada Gems example files are distributed by AdaCore and may be used or modified for any purpose without restrictions.

Safe typing is not about preventing heavy-handed use of the keyboard, although it can detect errors made by typos!

Safe typing is about designing the type structure of the language in order to prevent many common semantic errors. It is often known as strong typing.

Early languages such as Fortran and Algol treated all data as numeric types. Of course, at the end of the day, everything is indeed held in the computer as a numeric of some form, usually as an integer or floating point value and usually encoded using a binary representation. Later languages, starting with Pascal, began to recognize that there was merit in taking a more abstract view of the objects being manipulated. Even if they were ultimately integers, there was much benefit to be gained by treating colors as colors and not as integers by using enumeration types (just called scalar types in Pascal).

Ada take this idea much further as we shall see, but other languages still treat scalar types as just raw numeric types, and miss the critical idea of abstraction, which is to distinguish semantic intent from machine representation. The Ada approach provides more opportunities for detecting programming errors.

Read Chapter 2 in full

Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.

Today’s interconnected critical systems must be both safe and secure; software developers and decision makers need to understand the operative certification standards and their implications on technology choice and system development. This presentation first summarizes the DO-178B avionics safety standard and the Common Criteria / Common Evaluation Methodology security standard. It identifies the requirements that these standards impose on programming language technology and development tools, and explains how safety and security considerations are similar and how they differ. It describes how modern programming language features such as Object-Oriented Programming affect safety and security certification, and assesses several current language family approaches — C / C++, Ada / SPARK, and Java — against safety and security requirements.

Ada is a block-structured language, which means the programmer can nest blocks of code inside other blocks. At the end of a block, all objects declared inside of it go out of scope, meaning they no longer exist, so the language disallows pointers to objects in blocks with a deeper nesting level.

In order to prevent dangling references, every entity is associated with a number, called its “accessibility level”, according to a Ada’s accessibility rules. When certain references are made to an entity of an access type (Ada’s parlance for pointer), the accessibility level of the entity is checked against the level allowed by the context so that no dangling pointers can occur.

Consider the following example:

     procedure Static_Check is
        type Global is access all Integer;
        X : Global;

        procedure Init is
           Y : aliased Integer := 0;
        begin
           X := Y'Access; -- Illegal!
        end Init;
   
     begin
        Init;
        …
     end Static_Check;

The assignment is illegal because when the procedure Init finishes, the object Y no longer exists, thus making X a danging pointer. The compiler will detect this situation and flag the error.

The beauty of the accessibility rules is that most of them can be checked and enforced at compile time, just by using statically known accessibility levels.

However, there are cases when it is not possible to statically determine the accessibility level that an entity will have during program execution. In these cases, the compiler will insert a run-time check to raise an exception if a dangling pointer can be created:

     procedure Access_Params is
        type Integer_Access is access all Integer;
        Data : Integer_Access;

        procedure Init_Data (Value : access Integer) is
        begin
           Data := Integer_Access (Value);
           -- this conversion performs a dynamic accessibility check
        end;

        X : aliased Integer := 1;

     begin
        Init_Data (X'Access); -- This is OK 

        declare  
           Y : aliased Integer := 2;
        begin
           Init_Data (Y'Access); --  Trouble!
        end;
	--  Y no longer exists!

	Process (Data);
     end;

In the example above, we cannot know at compile time the accessibility level of the object that will be passed to Init_Data, so the compiler inserts a run-time check to make sure that the assignment ‘Data := …’ does not cause a dangling reference — and to raise an exception if it would.

In summary, when it comes to dangling references, Ada makes it very hard for you to shoot yourself in the foot!