 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Christian Kaufmann
Guest
|
 Posted: Fri Feb 04, 2005 9:18 am Post subject: Pool of interfaced objects |
 |
|
Hello,
I'm looking for an implementation of a pool of interfaced objects,
that can be used in a threaded environement. My idea of the interface
is something like this:
TMyObject = class(TInterfacedObject, IMyObject)
.....
end;
TObjectPool = class
private
FObjects : TInterfaceList;
public
constructor Create(APoolsize: Integer);
function GetObject: IMyObject
end;
In the constructor the objects are created. With GetObject() I
retreive an object from the pool. My problem is how to inform the
pool, when the last reference to the object is released.
Since such things are tricky in a threaded environment I'm looking for
a testet implementation, that works correctly. It would be nice, if
objects are created on demand up to a maximum number and requests
above this number would be queued.
cu Christian
|
|
| Back to top |
|
 |
Rudy Velthuis [TeamB]
Guest
|
| Posted: Fri Feb 04, 2005 12:06 pm Post subject: Re: Pool of interfaced objects |
|
|
Christian Kaufmann wrote:
| Quote: | In the constructor the objects are created. With GetObject() I
retreive an object from the pool. My problem is how to inform the
pool, when the last reference to the object is released.
|
I can only think of one way: the object must notify the pool in its
destructor.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Everyone is a genius at least once a year; a real genius has his
original ideas closer together."
- Georg Lichtenberg (1742-1799)
|
|
| Back to top |
|
|
Christian Kaufmann
Guest
|
| Posted: Fri Feb 04, 2005 1:39 pm Post subject: Re: Pool of interfaced objects |
|
|
| Quote: | I can only think of one way: the object must notify the pool in its
destructor.
I don't think, this is the solution, since I want a pool to avoid |
object creation/destruction.
I thought about checking RefCount of the object and if it is 1 (only
the reference of TInterfaceList on it, it is unused.
But I'm not sure, if I'm missing something.
cu Christian
|
|
| Back to top |
|
|
Rudy Velthuis [TeamB]
Guest
|
| Posted: Fri Feb 04, 2005 5:44 pm Post subject: Re: Pool of interfaced objects |
|
|
Christian Kaufmann wrote:
| Quote: | I can only think of one way: the object must notify the pool in its
destructor.
I don't think, this is the solution, since I want a pool to avoid
object creation/destruction.
|
Then it should notify the object pool when its reference count reaches
1, in the _Release method.
--
Rudy Velthuis [TeamB] http://rvelthuis.bei.t-online.de
"Dying is a very dull, dreary affair. And my advice to you is to have
nothing whatever to do with it." -- W. Somerset Maugham.
|
|
| Back to top |
|
|
Ritchie Annand
Guest
|
| Posted: Fri Feb 04, 2005 6:51 pm Post subject: Re: Pool of interfaced objects |
|
|
On Fri, 04 Feb 2005 10:18:15 +0100, Christian Kaufmann wrote:
| Quote: | In the constructor the objects are created. With GetObject() I
retreive an object from the pool. My problem is how to inform the
pool, when the last reference to the object is released.
|
We do a lot of interface-based development, and I must say that we had some
of the same pooling thoughts. It ended up that we could actually manually
return the objects to the pool and not lose any meaning.
That said, perhaps what you want to do in your case is make object
*delegates*, and give those out in GetObject, e.g.
TObjectDelegate = class(TInterfacedObject,IMyObject)
private
FActualObject : IMyObject;
FPool : IMyObjectPool;
public // IMyObject
procedure SomeMethod;
public
constructor Create(AActualObject: IMyObject; APool: IMyObjectPool);
destructor Destroy; override;
end;
constructor TObjectDelegate.Create(AActualObject: IMyObject;
APool: IMyObjectPool);
begin
inherited Create;
Assert(Assigned(AActualObject),ClassName+'::Create '+
'needs an object to wrap');
Assert(Assigned(APool),ClassName+'::Create needs a pool');
FActualObject := AActualObject;
FPool := APool;
end;
destructor TObjectDelegate.Destroy;
begin
FPool.Return(FActualObject);
inherited;
end;
procedure TObjectDelegate.SomeMethod;
begin
FActualObject.SomeMethod;
end;
You'll have to modify the approach if you port to .NET where there are no
explicit refcounts (judicious use of Finalize will help), but otherwise,
the idea should port.
| Quote: | Since such things are tricky in a threaded environment I'm looking for
a testet implementation, that works correctly. It would be nice, if
objects are created on demand up to a maximum number and requests
above this number would be queued.
|
That's one of our favorite approaches for threading. Our thread pool itself
operates on that principle :)
-- Ritchie
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
