* Controlled types for resource locking
@ 1999-09-08 0:00 Steve Folly
1999-09-08 0:00 ` David C. Hoos, Sr.
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Steve Folly @ 1999-09-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-08 0:00 Controlled types for resource locking Steve Folly
1999-09-08 0:00 ` David C. Hoos, Sr.
1999-09-08 0:00 ` Matthew Heaney
@ 1999-09-08 0:00 ` tmoran
1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Ted Dennison
2 siblings, 2 replies; 11+ messages in thread
From: tmoran @ 1999-09-08 0:00 UTC (permalink / raw)
>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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-08 0:00 Controlled types for resource locking Steve Folly
1999-09-08 0:00 ` David C. Hoos, Sr.
@ 1999-09-08 0:00 ` Matthew Heaney
1999-09-08 0:00 ` tmoran
2 siblings, 0 replies; 11+ messages in thread
From: Matthew Heaney @ 1999-09-08 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-08 0:00 Controlled types for resource locking Steve Folly
@ 1999-09-08 0:00 ` David C. Hoos, Sr.
1999-09-08 0:00 ` Matthew Heaney
1999-09-08 0:00 ` tmoran
2 siblings, 0 replies; 11+ messages in thread
From: David C. Hoos, Sr. @ 1999-09-08 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-08 0:00 ` tmoran
@ 1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Matthew Heaney
1999-09-09 0:00 ` Ted Dennison
1 sibling, 1 reply; 11+ messages in thread
From: Pat Rogers @ 1999-09-09 0:00 UTC (permalink / raw)
<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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-08 0:00 ` tmoran
1999-09-09 0:00 ` Pat Rogers
@ 1999-09-09 0:00 ` Ted Dennison
1999-09-09 0:00 ` Tucker Taft
1 sibling, 1 reply; 11+ messages in thread
From: Ted Dennison @ 1999-09-09 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-09 0:00 ` Pat Rogers
@ 1999-09-09 0:00 ` Matthew Heaney
1999-09-09 0:00 ` Pat Rogers
0 siblings, 1 reply; 11+ messages in thread
From: Matthew Heaney @ 1999-09-09 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-09 0:00 ` Ted Dennison
@ 1999-09-09 0:00 ` Tucker Taft
0 siblings, 0 replies; 11+ messages in thread
From: Tucker Taft @ 1999-09-09 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-09 0:00 ` Matthew Heaney
@ 1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Matthew Heaney
0 siblings, 1 reply; 11+ messages in thread
From: Pat Rogers @ 1999-09-09 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-09 0:00 ` Pat Rogers
@ 1999-09-09 0:00 ` Matthew Heaney
1999-09-09 0:00 ` Pat Rogers
0 siblings, 1 reply; 11+ messages in thread
From: Matthew Heaney @ 1999-09-09 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Controlled types for resource locking
1999-09-09 0:00 ` Matthew Heaney
@ 1999-09-09 0:00 ` Pat Rogers
0 siblings, 0 replies; 11+ messages in thread
From: Pat Rogers @ 1999-09-09 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-09-09 0:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-08 0:00 Controlled types for resource locking Steve Folly
1999-09-08 0:00 ` David C. Hoos, Sr.
1999-09-08 0:00 ` Matthew Heaney
1999-09-08 0:00 ` tmoran
1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Matthew Heaney
1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Matthew Heaney
1999-09-09 0:00 ` Pat Rogers
1999-09-09 0:00 ` Ted Dennison
1999-09-09 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox