A number of semaphore definitions exist, although the general concept remains as introduced by Dijkstra in 1968. We assume the reader has some familiarity with semaphores and their semantics, and so we will not cover them here. Many books are available for those requiring additional information. See especially Principles of Concurrent and Distributed Programming by M. Ben-Ari.

The GNAT.Semaphores package defines two semaphore abstractions, both in terms of protected types. We use protected types, rather than defining abstract data types based on operating-system facilities, for the sake of portability. A simple wrapper around the facilities of an operating system or RTOS would be reasonable, but the resulting interface (and implementation, of course) would not have the portability required of the general-purpose GNAT hierarchy.

The first abstraction defines a “counting” semaphore, in which an integer count is maintained by the operations, such that the acquire operation only executes (and thus returns, allowing the caller to continue) when the count is greater than zero. Counting semaphores are convenient for expressing condition synchronization in terms of the availability of some number of resources. For example, with a circular bounded buffer, a semaphore’s count can represent the number of available buffer slots. Callers must wait for the buffer to be non-full when attempting to insert a new item, and the blocking call to acquire the semaphore will achieve that effect directly.

The declaration for the counting semaphore is as follows. Note that we have removed the in-line comments for the sake of brevity, but will cover their content.

   protected type Counting_Semaphore
      (Initial_Value : Natural;
      Ceiling : System.Priority)
   is
      pragma Priority (Ceiling);

      entry Seize;
      procedure Release;

   private
      Count : Natural := Initial_Value;
   end Counting_Semaphore;

The second type implements “binary” semaphores. This kind of semaphore is less flexible than the counting semaphore, in that no notion of a count is maintained. The abstraction is simply that of a flag indicating whether or not the semaphore is available. (If the value of a counting semaphore varied between zero and one, the effect would be the same.)

   protected type Binary_Semaphore
     (Initially_Available : Boolean;
      Ceiling : System.Priority)
   is
      pragma Priority (Ceiling);

      entry Seize;
      procedure Release;

   private
      Available : Boolean := Initially_Available;
   end Binary_Semaphore;

In both cases, the provided operations consist of an entry “Seize” to acquire the semaphore with mutually exclusive access, and a protected procedure “Release” to release it. The Seize operation must be an entry for the sake of the barrier expressing the required condition synchronization. Releasing the semaphore has no such requirement, so it need not be an entry.

Both types are visibly defined as protected types so that users can make conditional and timed calls when appropriate. This capability addresses one of the portability problems with semaphores. Although the basic “acquire” and “release” operations will always be provided (by whatever name), there is no “standard” interface for other forms of interaction. Language-defined constructs provide some of those kinds of interactions, and do so portably.

Both types require discriminants. The counting semaphore type uses a discriminant to specify the initial nonnegative value of the count. The binary semaphore type uses a Boolean discriminant to specify whether the semaphore should be initially available. For example, a binary semaphore would be initially available when used to express mutual exclusion, but might not be initially available when used to express condition synchronization.

In addition, both types use another discriminant to specify the ceiling priority for objects of the type. The discriminant is then passed as the argument to pragma Priority. If the Real-Time Systems Annex is in force this part is essential; otherwise it has no effect. Note that a default value cannot be provided for the Ceiling discriminant because that would require a default for the other discriminant, too. The best we can do is to define a convenient value to be used in declarations of individual objects when the Real-Time Annex is not in force, so the following constant is provided in GNAT.Semaphores:

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

However, subtypes can be used to enhance convenience, readability and robustness. The earlier Gem (#70) provided an example:

   subtype Mutual_Exclusion is Binary_Semaphore
     (Initially_Available => True,
      Ceiling             => Default_Ceiling);

The subtype ensures that corresponding objects are initially available, but also conveniently supplies the Ceiling discriminant value (assuming the Real-Time Annex is not in force) and gives the reader an indication of the intended use.

As you can see, the declarations of protected types can be very expressive. The discriminants are the part you might not have considered using, although that is by no means an unusual approach. The protected bodies of both types are trivial and will not be shown here. You can see them in the GNAT hierarchy, along with the implementations of all the other GNAT hierarchy packages.

Introduction

Ada 95 brought us the predefined package Interfaces, with its standard definitions for types like Unsigned_32 and so on. It also defines various functions to do common shift and rotate operations on those types, such as:

   function Shift_Left
     (Value  : Unsigned_32;
      Amount : Natural) return Unsigned_32;

In GNAT Pro, these function declarations are also followed by a curious-looking pragma:

   pragma Import (Intrinsic, Shift_Left);

The Ada 95 RM (6.3.1) says:

‘The intrinsic calling convention represents subprograms that are “built in” to the compiler.’

This basically means that the code generator “knows” how to implement these functions. In the case of shifts and rotates, this means that a call to one of these functions results in very few (possibly just one) machine instructions — giving the performance you’d expect from such a simple operation.

Shifts and rotates are useful in a wide variety of applications, but are endemic in cryptographic algorithms, where they appear all over the place.

Unfortunately, the standard specification of package Interfaces is not legal SPARK, since the various shift and rotate functions are overloaded for each of the modular types, and overloading within a scope is not allowed. Darn…

To get round this, we first introduce a “shadow” specification of Interfaces that supplies the legal SPARK bits that we’re interested in — specifically the type declarations, thus:

   package Interfaces is
      type Unsigned_8  is mod 2**8;
      type Unsigned_16 is mod 2**16;
      type Unsigned_32 is mod 2**32;
      type Unsigned_64 is mod 2**64;
   end Interfaces;

This is legal SPARK, and goes in a file called interfaces.shs. We then use the Examiner’s index-file mechanism to make sure that the Examiner sees this version of the package specification.

To get at the shift and rotate functions, we need to introduce a new package that “de-overloads” the names. Let’s call this package “SR” — this is also a “shadow”, so it goes in sr.shs or a similar file. It looks like this:

   with Interfaces;
   --# inherit Interfaces;
   package SR is

      function Rotate_Left_16
        (Value  : Interfaces.Unsigned_16;
         Amount : Natural) return Interfaces.Unsigned_16;

      function Rotate_Left_32
        (Value  : Interfaces.Unsigned_32;
         Amount : Natural) return Interfaces.Unsigned_32;

      -- ...and so on for all required functions...
   end SR;

Note how we removed the overloading of the function names.

OK… so how do we glue package SR to the predefined intrinsic functions in package Interfaces?

It’s tempting to just implement the body of SR (in Ada, not SPARK) to “call through” to the appropriate function in Interfaces, but this might involve the overhead of a full-blown function call/return sequence, losing all that juicy performance that the intrinsic functions give us. We could try using pragma Inline to get rid of that overhead, but, as car salesmen say, “your mileage may vary” with that idea.

Fortunately, there is a way out that preserves the efficiency of the intrinsic version. Remember that the specification of SR above is a shadow? We supply the following slightly different version to the compiler in sr.ads:

   with Interfaces;
   package SR is

      function Rotate_Left_16
        (Value  : Interfaces.Unsigned_16;
         Amount : Natural) return Interfaces.Unsigned_16 renames Interfaces.Rotate_Left;

      function Rotate_Left_32
        (Value  : Interfaces.Unsigned_32;
         Amount : Natural) return Interfaces.Unsigned_32 renames Interfaces.Rotate_Left;

      -- ...and so on
   end SR;

The renaming here ensures that our SPARK-friendly “un-overloaded” functions are synonymous with the intrinsic “built in” functions, getting us the best of both worlds — the type safety of SPARK, with the efficiency of intrinsic machine code!

The full article can be found at:
http://embedded-computing.com/integrating-static-analysis-a-compiler-database