Re: High-Integrity OO and controlled types

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 04.05.11 11:28, Dmitry A. Kazakov wrote:

> This does not read as a complete description. In what sense are the parts
> of the array shared? If sharing means only independent use of the parts,
> then what sense has the array as an object in this design? Independently
> used parts must be local to their users. Now, if there is something else
> behind this, i.e. that parts are sometimes used independently and sometimes
> together, then too little is said about the mechanisms used for the latter,
> and most intricate part of design.
> 
>> This sounds like one could design types that
>> do(!) just this as part of their finalization.  But it does
>> seem like an awful lot of overhead, and is essentially
>> a type that is-a procedure.
> 
> You see that as an overhead only because the picture is incomplete. Once
> you fill the gaps, you will see how "exit action" firs there. That would
> definitely involve additional objects, e.g. controlled "handles" of which
> finalization would deal with "exit" and other operations would serve
> interlocking etc.

A simple example (full source linked, but may not be
necessary); the intention is for it to be fairly low
level data manipulation.  It is not nice, and could be
generalized in several ways, I think.  If there is
justification for doing so.

Array `Central` is manipulated by two tasks A and B.
When these have finished filling `Central`, the env task
computes the final result by counting certain values in `Central`.
Communication uses simple variables and visibility.

The task B is sensitive to a special piece of input
and will restart its work from the beginning when
the input testing function raises Junk_Signal.

I imagine it is possible to redesign, yet I'd like to know
the ROI; the program is almost a Ravenscar program.
There are no pointers.


with Printing;

procedure Shared is

    -- ----------------------------------------------------------------
    --  Outline:
    --
    --  Two tasks will work on a shared array, each task taking care of
    --  its share of slots.  After they have finished, all slots will
    --  have valid values, some of which are interesting.  Count
    --  these.
    -- ----------------------------------------------------------------

    package Stuff is
	--
	--  Items that will be stored in the array.  Each component
	--  will be of type ID_Code.  No value means = No_Code.
	--
	type Digit_Position is range 1 .. 4;
	type Code_Digit is ('U', 'V', 'W', 'X', 'Y', 'Z');
	type ID_Code is array (Digit_Position) of Code_Digit;
	No_Code : constant ID_Code;
	
	function Image (Id : Id_Code) return String;
	
	type Slot_Index is range 1 .. 1023;
	type Work_Item is array (Slot_Index) of ID_Code;
	--  type of the shared array
	
	function Is_Filled (W : Work_Item) return Boolean;
	procedure Init (W : in out Work_Item);
	
	function Interesting_Result (W : Work_Item) return Natural;
	--  number of interesting ID_Code values in `W` (likely `Central`)
	
    private
	No_Code : constant ID_Code := ID_Code'('X', 'X', 'X', 'X');
    end Stuff;

    package body Stuff is separate;

    use Stuff;

    Central : Work_Item;
    Result : Natural := Natural(Slot_Index'Last) + 1;
    --  also used as flag. Set `Result := 0` when the tasks may start
    --  doing their work
    pragma Atomic(Result);

    package Slaves is
	--  Each task will work with its share of slots in `Central`.
	--  A and B try hard to find good ID_Code values from some
	--  external source, B tries especially hard.
	task A;
	task B;
    end Slaves;

    package body Slaves is separate;
		
begin
    Init (Central);
    pragma Assert (not Is_Filled (Central));
    Result := 0;
    -- now poll until A and B have filled Central
    loop
	exit when Is_Filled (Central);
	delay 0.2;
    end loop;
    Result := Interesting_Result(Central);
    Printing.Output.Write  (Natural'Image(Result)
			      & " interesting items",
			    NL => True);
end Shared;

Rest is here:
http://home.arcor.de/bauhaus/Ada/shrd.ada