guideline

Use caution with conditional entry calls to task entries.

Use caution with selective accept with else parts.

Do not depend upon a particular delay in timed entry calls to task entries.

Do not depend upon a particular delay in selective accepts with delay alternatives.

Consider using protected objects instead of the rendezvous for data-oriented synchronization.

The conditional entry call in the following code results in a potential race condition that might degenerate into a busy waiting loop (i.e., perform the same calculation over and over). The task Current_Position containing entry Request_New_Coordinates might never execute if the loop-containing task (shown in the following code fragment) has a higher priority than Current_Position because it does not release the processing resource:

task body Calculate_Flightpath is
begin
   ...
   loop
  
      select
         Current_Position.Request_New_Coordinates (X, Y);
         -- calculate projected location based on new coordinates
         ...
  
      else
         -- calculate projected location based on last locations
         ...
      end select;
  
   end loop;
   ...
end Calculate_Flightpath;

The addition of a delay, as shown, may allow Current_Position to execute until it reaches an accept for Request_New_Coordinates:

task body Calculate_Flightpath is
begin
   ...
   loop
  
      select
         Current_Position.Request_New_Coordinates(X, Y);
         -- calculate projected location based on new coordinates
         ...
  
      else
         -- calculate projected location based on last locations
         ...
  
         delay until Time_To_Execute;
         Time_To_Execute := Time_To_Execute + Period;
      end select;
  
   end loop;
   ...
end Calculate_Flightpath;

The following selective accept with else again does not degenerate into a busy wait loop only because of the addition of a delay statement:

task body Buffer_Messages is

   ...

begin

   ...

   loop
      delay until Time_To_Execute;

      select
         accept Get_New_Message (Message : in     String) do
            -- copy message to parameters
            ...
         end Get_New_Message;
      else  -- Don't wait for rendezvous
         -- perform built in test Functions
         ...
      end select;

      Time_To_Execute := Time_To_Execute + Period;
   end loop;

   ...

end Buffer_Messages;

The following timed entry call might be considered an unacceptable implementation if lost communications with the reactor for over 25 milliseconds results in a critical situation:

task body Monitor_Reactor is
   ...
begin
   ...
   loop
  
      select
         Reactor.Status(OK);
  
      or
         delay 0.025;
         -- lost communication for more that 25 milliseconds
         Emergency_Shutdown;
      end select;
  
      -- process reactor status
      ...
   end loop;
   ...
end Monitor_Reactor;

In the following "selective accept with delay" example, the accuracy of the coordinate calculation function is bounded by time. For example, the required accuracy cannot be obtained unless Period is within + or - 0.005 seconds. This period cannot be guaranteed because of the inaccuracy of the delay statement:

task body Current_Position is
begin
   ...
   loop
  
      select
         accept Request_New_Coordinates (X :    out Integer;
                                         Y :    out Integer) do
            -- copy coordinates to parameters
            ...
         end Request_New_Coordinates;
  
      or
         delay until Time_To_Execute;
      end select;
  
      Time_To_Execute := Time_To_Execute + Period;
      -- Read Sensors
      -- execute coordinate transformations
   end loop;
   ...
end Current_Position;

rationale

Use of these constructs always poses a risk of race conditions. Using them in loops, particularly with poorly chosen task priorities , can have the effect of busy waiting.