Controlled types for resource locking

Controlled types for resource locking

[Steve Folly]

Hi,

A couple of months ago (maybe more?) I remember somebody posted some code,
or a link to some code to do with controlled types and how they can be
useful for resource locking.

If anyone remembers this, or indeed if you were the person who posted it, I
would be grateful for any link or reference to it.

I have some code in which I'm protecting a hardware resource using a
protected type. It's getting quite a mess at the moment with lock/unlocks
all over the place - especially where exception handlers get involved. I'm
sure this code could come in handy.

Thanks v. much.

--
Regards,
Steve Folly -  Y2K compliant since 32nd Februark 1998
http://www.follysplace.demon.co.uk
donationsto:myaccount@mybank.co.uk

Re: Controlled types for resource locking

[tmoran]

>I have some code in which I'm protecting a hardware resource using a
>protected type. It's getting quite a mess at the moment with lock/unlocks
>all over the place - especially where exception handlers get involved. I'm
  You can make a controlled type whose Initialize grabs the lock and
whose Finalize releases it, then declare an object of this controlled
type as the first thing in any subprogram (or block) that needs access
to the hardware.  Thus you can't execute code inside the subprogram
till the Initialize has been called, and you own the resource.  Any way
you leave the subprogram, you are guaranteed the Finalize will release
the resource.
  p.s.  There was a bug in a compiler I used a year or so ago, and
which I believe has since been fixed, such that Finalize would be
called even if Initialize had failed (raised a Cant_Get_Resource
exception, for instance).  Make sure nothing like that is happening
with your system.

Re: Controlled types for resource locking

[Matthew Heaney]

In article <936824686.950.0.nnrp-07.c2de848f@news.demon.co.uk> , "Steve 
Folly" <steve@follysplace.demon.co.uk> wrote:


> A couple of months ago (maybe more?) I remember somebody posted some code,
> or a link to some code to do with controlled types and how they can be
> useful for resource locking.
>
> If anyone remembers this, or indeed if you were the person who posted it, I
> would be grateful for any link or reference to it.

I did a bunch of examples of this for the Ada95 design patterns list.  All
of my posts were archived:

<http://www.acm.org/archives/patterns.html>

The idiom you're looking for was done this year (1999), around April.  There
were several implementations of the Dining Philosophers problem, each
featuring different resource control techniques.

I'll be covering this stuff in my Design Patterns tutorial at this year's
SIGAda conference.


> I have some code in which I'm protecting a hardware resource using a
> protected type. It's getting quite a mess at the moment with lock/unlocks
> all over the place - especially where exception handlers get involved. I'm
> sure this code could come in handy.

Yep.  The basic idea goes something like this:

package Semaphores.Binary is

  protected type Semaphore_Type is

    entry Seize;
    procedure Release;

  end Semaphore_Type;

end Semaphores.Binary;


package Semaphores.Binary.Controls is

  type Semaphore_Control
    (Semaphore : access Semaphore_Type) is limited private;

private

  type Semaphore_Control (...) is
    new Limited_Controlled with null record;

  procedure Initialize (...);

  procedure Finalize (...);

end Semaphores.Binary.Controls;


package body Semaphores.Binary.Controls is

  procedure Initialize (Control : in out Sema_Cont) is
  begin
    Control.Semaphore.Seize;
  end;

  procedure Finalize (Control : in out Sema_Cont) is
  begin
    Control.Semaphore.Release;
  end;

end Semaphores.Binary.Controls;



You use it like this:

package body P is

  Sema : aliased Semaphore_Type;

  procedure Op is
    Control : Semaphore_Control (Sema'Access);
  begin
    <do whatever, even if it raises an exception>
  end Op;

...
end P;

You can even do it in an ordinary declare-block:

  declare
    Control : Semaphore_Control (Sema'Access);
  begin
    <do your little algorithm here>
  end;


Of course, this isn't the quite the same as using a protected object
directly, to manage access to the resource.  With a protected operation, you
can't make blocking calls, which often makes it unusable as a resource
control mechanism.  The approach I've shown above does not suffer from this
limitation, although it's likely to be slightly less efficient.  It's a
trade-off.

Matt

P.S. BTW, this limitation of protected objects is something the language
maintainers need to address.

Re: Controlled types for resource locking

[David C. Hoos, Sr.]

Steve Folly <steve@follysplace.demon.co.uk> wrote in message
news:936824686.950.0.nnrp-07.c2de848f@news.demon.co.uk...
> Hi,
>
> A couple of months ago (maybe more?) I remember somebody posted some code,
> or a link to some code to do with controlled types and how they can be
> useful for resource locking.
>
> If anyone remembers this, or indeed if you were the person who posted it,
I
> would be grateful for any link or reference to it.
>
> I have some code in which I'm protecting a hardware resource using a
> protected type. It's getting quite a mess at the moment with lock/unlocks
> all over the place - especially where exception handlers get involved. I'm
> sure this code could come in handy.
>
The code (or a reference to it) was posted by Matthew Heaney.  Here's a copy
(possibly with some editing by me -- I don't remember.  I think the code
comes from the patterns archive of the ACM for which the URL is:

http://www.acm.org/archives/wa.cgi?A2=ind9903&L=patterns&P=R11595

There's commentary there.

Here's my copy of the code
package body Binary_Semaphores.Controls is

   procedure Initialize (Control : in out Semaphore_Control) is
   begin
      Control.Semaphore.Seize;
   end;

   procedure Finalize (Control : in out Semaphore_Control) is
   begin
      Control.Semaphore.Release;
   end;

end Binary_Semaphores.Controls;
with Ada.Finalization;

package Binary_Semaphores.Controls is

   pragma Preelaborate;

   type Semaphore_Control (Semaphore : access Semaphore_Type) is
      limited private;

private

   use Ada.Finalization;

   type Semaphore_Control (Semaphore : access Semaphore_Type) is
     new Limited_Controlled with null record;

   procedure Initialize (Control : in out Semaphore_Control);

   procedure Finalize (Control : in out Semaphore_Control);

end Binary_Semaphores.Controls;
package body Binary_Semaphores is

   protected body Semaphore_Type is

      procedure Release is
      begin
         In_Use := False;
      end;

      entry Seize when not In_Use is
      begin
         In_Use := True;
      end;

   end Semaphore_Type;

end Binary_Semaphores;
package Binary_Semaphores is

   pragma Pure;


   protected type Semaphore_Type is

      procedure Release;

      entry Seize;

   private

      In_Use : Boolean := False;

   end Semaphore_Type;

end Binary_Semaphores;
with Binary_Semaphores.Controls;  use Binary_Semaphores.Controls;

with System.Address_To_Access_Conversions;
pragma Elaborate_All (System.Address_To_Access_Conversions);

package body Stacks is

   package Addr_To_Acc_Conversions is
     new System.Address_To_Access_Conversions (Stack_Type);


   procedure Push
     (Item : in     Item_Type;
      On   : in out Stack_Type) is

      Control : Semaphore_Control (On.Sema'Access);
   begin
      On.Top := On.Top + 1;
      On.Items (On.Top) := Item;
   end;


   procedure Pop
     (Stack : in out Stack_Type) is

      Control : Semaphore_Control (Stack.Sema'Access);
   begin
      Stack.Top := Stack.Top - 1;
   end;


   function Get_Top
     (Stack : Stack_Type) return Item_Type is

      use Addr_To_Acc_Conversions;

      SA : constant Object_Pointer :=
        To_Pointer (Stack'Address);

      Control : Semaphore_Control (SA.Sema'Access);

   begin

      return SA.Items (SA.Top);

   end Get_Top;



   procedure Set_Top
     (Stack : in out Stack_Type;
      Item  : in     Item_Type) is

      Control : Semaphore_Control (Stack.Sema'Access);
   begin
      Stack.Items (Stack.Top) := Item;
   end;


   procedure For_Every_Item (Stack : in out Stack_Type) is

      Control : Semaphore_Control (Stack.Sema'Access);

      Done : Boolean := False;

   begin

      for I in reverse 1 .. Stack.Top loop

         Process (Stack.Items (I), Done);

         exit when Done;

      end loop;

   end For_Every_Item;


end Stacks;





with Binary_Semaphores;

generic

   type Item_Type is private;

   Max_Depth : in Positive;

package Stacks is

   pragma Preelaborate;

   type Stack_Type is limited private;


   procedure Push
     (Item : in     Item_Type;
      On   : in out Stack_Type);

   procedure Pop
     (Stack : in out Stack_Type);

   function Get_Top
     (Stack : Stack_Type) return Item_Type;

   procedure Set_Top
     (Stack : in out Stack_Type;
      Item  : in     Item_Type);


   generic

      with procedure Process
        (Item : in out Item_Type;
         Done : in out Boolean);

   procedure For_Every_Item (Stack : in out Stack_Type);

private

   subtype Item_Array_Range is Positive range 1 .. Max_Depth;

   type Item_Array is array (Item_Array_Range) of Item_Type;

   use Binary_Semaphores;

   type Stack_Type is
      limited record
         Items : Item_Array;
         Top   : Natural := 0;
         Sema  : aliased Semaphore_Type;
      end record;

end Stacks;

Re: Controlled types for resource locking

[Pat Rogers]

<tmoran@bix.com> wrote in message
news:iMAB3.157$QV.27052@typhoon-sf.pbi.net...
> > I have some code in which I'm protecting a hardware resource using a
> > protected type. It's getting quite a mess at the moment with
lock/unlocks
> > all over the place - especially where exception handlers get
involved. I'm
>
> You can make a controlled type whose Initialize grabs the lock and
> whose Finalize releases it, then declare an object of this controlled
> type as the first thing in any subprogram (or block) that needs access
> to the hardware.  Thus you can't execute code inside the subprogram
> till the Initialize has been called, and you own the resource.  Any
way
> you leave the subprogram, you are guaranteed the Finalize will release
> the resource.

Further to Tom's suggestion, let me suggest you make it a limited
controlled type and use an access discriminant to identify the object
you wish to have automatically locked and unlocked.  Here's how I would
do it, for example:

Here we create an interface for things that can be locked and unlocked:

package Lockable is
  type Thing is abstract tagged limited null record;
  procedure Lock  ( This : in  out Thing ) is abstract;
  procedure Unlock( This : in  out Thing ) is abstract;
end Lockable;


We also create a template to add the automatic locking/unlocking
behaviour.  Once instantiated, the generic package exports a type that
will automatically lock and unlock objects designated by the
discriminants of objects of type Managed_Resource.  the generic formal
parameter says that users can only instantiate this generic with types
that are directly or indirectly lockable:


with Ada.Finalization;
with Lockable;

generic
  type Unmanaged_Resource is new Lockable.Thing with private;
package Locking_Manager is

  type Managed_Resource( Resource : access Unmanaged_Resource ) is
    tagged limited private;

private

  type Managed_Resource( Resource : access Unmanaged_Resource ) is
    new Ada.Finalization.Limited_Controlled with null record;

  procedure Initialize( This : in out Managed_Resource );
  procedure Finalize  ( This : in out Managed_Resource );

end Locking_Manager;


We know that the discriminant designates a lockable thing, so we
dispatch to the operations within Initialize and Finalize, which are
called when the object is elaborated and finalized (only, since it is a
limited type):

package body Locking_Manager is


  procedure Initialize( This : in out Managed_Resource ) is
  begin
    Lockable.Lock( Lockable.Thing'Class(This.Resource.all) );
  end Initialize;


  procedure Finalize( This : in out Managed_Resource ) is
  begin
    Lockable.Unlock( Lockable.Thing'Class(This.Resource.all) );
  end Finalize;


end Locking_Manager;


Here's an instance of a lockable app type, completely made up.  (The
package Blocking is available at the free code section of my web site.)

with Lockable;
with Blocking;

package Database is

  type Homogeneous_View is new Lockable.Thing with private;

  -- primitive operations on Homogeneous_View objects

  procedure Lock( This : in out Homogeneous_View );

  procedure Unlock( This : in out Homogeneous_View );

private

  type Homogeneous_View is new Lockable.Thing with
    record
      Mutex : Blocking.Mutual_Exclusion;
      -- components required for whatever this really is
    end record;

end Database;


package body Database is

  -- primitive ops bodies

  procedure Lock( This : in out Homogeneous_View ) is
  begin
    This.Mutex.Acquire;
  end Lock;

  procedure Unlock( This : in out Homogeneous_View ) is
  begin
    This.Mutex.Release;
  end Unlock;

end Database;


Here we instantiate the generic:


with Database;
with Locking_Manager;

package Managed_Views is
  new Locking_Manager( Unmanaged_Resource =>
Database.Homogeneous_View );


And here's a demo.  We just work with View, confident that
Automatic_Lock handles the locking and unlocking for us:

with Database;
with Managed_Views;

procedure Test is

  View : aliased Database.Homogeneous_View;

  Automatic_Lock : Managed_Views.Managed_Resource( View'Access );

begin
  -- operations on View ...
end Test;


Hope that helps,


--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com       Software Fault Tolerance
(281)648-3165                        Real-Time/OO Languages

Re: Controlled types for resource locking

[Ted Dennison]

In article <iMAB3.157$QV.27052@typhoon-sf.pbi.net>,
  tmoran@bix.com wrote:
> >I have some code in which I'm protecting a hardware resource using a
> >protected type. It's getting quite a mess at the moment with
lock/unlocks
> >all over the place - especially where exception handlers get
involved. I'm
>   You can make a controlled type whose Initialize grabs the lock and
> whose Finalize releases it, then declare an object of this controlled
> type as the first thing in any subprogram (or block) that needs access
> to the hardware.  Thus you can't execute code inside the subprogram

Interesting. In effect you are creating an object just for its side
effects. But if that's all you ever do with the object, wouldn't it be
in danger of being optimized away by the compiler? Or are compilers not
allowed to do that with controlled objects?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Controlled types for resource locking

[Matthew Heaney]

In article <rtff5h311iv34@corp.supernews.com> , "Pat Rogers" 
<progers@NOclasswideSPAM.com> wrote:

> with Ada.Finalization;
> with Lockable;
>
> generic
>   type Unmanaged_Resource is new Lockable.Thing with private;
> package Locking_Manager is
>
>   type Managed_Resource( Resource : access Unmanaged_Resource ) is
>     tagged limited private;
>
...
> end Locking_Manager;

Realize that there's no reason to import a formal tagged derived type.  A
simpler approach is to just import a private type and some operations:

generic
  type Resource_Type (<>) is limited private;
  with procedure Lock (Resource : in out Resource_Type) is <>;
  with procedure Unlock (Resource : in out Resource_Type) is <>;
package Locking_Manager is ...;

This will work for resources that are tagged or untagged.

If you want to dispatch lock and unlock, that's possible too.  Just import a
class-wide op that calls the primitive op:

package P is

  type Root_Resource_Type is abstract tagged limited private;

  procedure Lock (Resource : in out ...);
  procedure Unlock (Resource : ...);

...
end P;

Just write two small class-wide ops:

package P.Dispatching_Utils is

  procedure Call_Lock (Resource : in out Resource_Type'Class);

  procedure Call_Unclock (Resource : in out Resource_Type'Class);

end;

package body P.Dispatching_Utils is

  procedure Call_Lock (Resource : in out Resource_Type'Class) is
  begin
    Lock (Resource);
  end;

  ...
end;

Now just supply the class-wide type and the util ops to the instantiation:

with P.Dispatching_Utils, Locking_Manager;

package Lock_Resources is
  new Locking_Manager (Resource_Type'Class, Call_Lock, Call_Unlock);


Et viola!  The calls to Lock and Unlock dispatch.

In general, I prefer not to import a type hierarchy unless I really have to.

I'll be discussing this technique in my Design Patterns tutorial at this
year's SIGAda conference.


> package body Locking_Manager is
>
>
>   procedure Initialize( This : in out Managed_Resource ) is
>   begin
>     Lockable.Lock( Lockable.Thing'Class(This.Resource.all) );
>   end Initialize;

   procedure Init (...) is
   begin
     Lock (This);
   end;


>   procedure Finalize( This : in out Managed_Resource ) is
>   begin
>     Lockable.Unlock( Lockable.Thing'Class(This.Resource.all) );
>   end Finalize;
>
>
> end Locking_Manager;

Re: Controlled types for resource locking

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <iMAB3.157$QV.27052@typhoon-sf.pbi.net>,
>   tmoran@bix.com wrote:
> > >I have some code in which I'm protecting a hardware resource using a
> > >protected type. It's getting quite a mess at the moment with
> lock/unlocks
> > >all over the place - especially where exception handlers get
> involved. I'm
> >   You can make a controlled type whose Initialize grabs the lock and
> > whose Finalize releases it, then declare an object of this controlled
> > type as the first thing in any subprogram (or block) that needs access
> > to the hardware.  Thus you can't execute code inside the subprogram
> 
> Interesting. In effect you are creating an object just for its side
> effects. But if that's all you ever do with the object, wouldn't it be
> in danger of being optimized away by the compiler? Or are compilers not
> allowed to do that with controlled objects?

Limited controlled objects may not be optimized away.
There is an AI being debated that would formalize this further,
and probably disallow optimizing away non-limited controlled objects
when there is a user-defined Initialize procedure.
> 
> --
> T.E.D.
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Controlled types for resource locking

[Pat Rogers]

Matthew Heaney <matthew_heaney@acm.org> wrote in message
news:37d7cee7@news1.prserv.net...
> In article <rtff5h311iv34@corp.supernews.com> , "Pat Rogers"
> <progers@NOclasswideSPAM.com> wrote:
>
> > with Ada.Finalization;
> > with Lockable;
> >
> > generic
> >   type Unmanaged_Resource is new Lockable.Thing with private;
> > package Locking_Manager is
> >
> >   type Managed_Resource( Resource : access Unmanaged_Resource ) is
> >     tagged limited private;
> >
> ...
> > end Locking_Manager;
>
> Realize that there's no reason to import a formal tagged derived type.
A
> simpler approach is to just import a private type and some operations:
>
> generic
>   type Resource_Type (<>) is limited private;
>   with procedure Lock (Resource : in out Resource_Type) is <>;
>   with procedure Unlock (Resource : in out Resource_Type) is <>;
> package Locking_Manager is ...;
>
> This will work for resources that are tagged or untagged.
>
> If you want to dispatch lock and unlock, that's possible too.  Just
import a
> class-wide op that calls the primitive op:
>
> package P is
>
>   type Root_Resource_Type is abstract tagged limited private;
>
>   procedure Lock (Resource : in out ...);
>   procedure Unlock (Resource : ...);
>
> ...
> end P;
>
> Just write two small class-wide ops:
>
> package P.Dispatching_Utils is
>
>   procedure Call_Lock (Resource : in out Resource_Type'Class);
>
>   procedure Call_Unclock (Resource : in out Resource_Type'Class);
>
> end;
>
> package body P.Dispatching_Utils is
>
>   procedure Call_Lock (Resource : in out Resource_Type'Class) is
>   begin
>     Lock (Resource);
>   end;
>
>   ...
> end;
>
> Now just supply the class-wide type and the util ops to the
instantiation:
>
> with P.Dispatching_Utils, Locking_Manager;
>
> package Lock_Resources is
>   new Locking_Manager (Resource_Type'Class, Call_Lock, Call_Unlock);
>
>
> Et viola!  The calls to Lock and Unlock dispatch.
>
> In general, I prefer not to import a type hierarchy unless I really
have to.


"Simpler is in the eye of the beholder".  :-)  I find it simpler to do
it the other way, but not greatly so.  Too, I had originally done it as
a mix-in, so that the exported type was in the class of the imported
type, but I don't like having to do view conversions to get the parent's
primitive operations when using the child type.


> I'll be discussing this technique in my Design Patterns tutorial at
this
> year's SIGAda conference.


When is the book coming out?


--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com       Software Fault Tolerance
(281)648-3165                        Real-Time/OO Languages

Re: Controlled types for resource locking

[Matthew Heaney]

In article <rtfpr6pv1iv73@corp.supernews.com> , "Pat Rogers" 
<progers@NOclasswideSPAM.com> wrote:


> "Simpler is in the eye of the beholder".  :-)  I find it simpler to do
> it the other way, but not greatly so.

Perhaps I should have said "more flexible."

My issue with your approach is that the generic only works for types in that
one class (of the imported type).

The other way, the generic works for *any* class, and decouples the
abstractions.


>> I'll be discussing this technique in my Design Patterns tutorial at this
>> year's SIGAda conference.
>
>
> When is the book coming out?

Don't know yet.  I have a couple of book ideas, but I've been busy getting
the tutorial slides done for Dave Cook.  That's done, so now I can finally
start writing...

(And I haven't forgotten my promise to you to write some design pattern
articles for Ada Letters...)

Matt

Re: Controlled types for resource locking

[Pat Rogers]

Matthew Heaney <matthew_heaney@acm.org> wrote in message
news:37d8245a@news1.prserv.net...
> In article <rtfpr6pv1iv73@corp.supernews.com> , "Pat Rogers"
> <progers@NOclasswideSPAM.com> wrote:
>>
> > When is the book coming out?
>
> Don't know yet.  I have a couple of book ideas, but I've been busy
getting
> the tutorial slides done for Dave Cook.  That's done, so now I can
finally
> start writing...

Excellent.  I think this would be a very useful book for the Ada
community.

> (And I haven't forgotten my promise to you to write some design
pattern
> articles for Ada Letters...)

I'm glad to hear that!  :-)


--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages