Preloading Bindings + concurrency
37 views
Skip to first unread message
TWischmeier
Nov 26, 2009, 8:39:56 AM11/26/09
to ninject
Hi,
I would like to implement a pre-loading mechanism in my application.
When the user enters certain areas, I know for certain that he will
step through a series of Windows Forms (and some associated objects).
Luckily, there are some initial network communication actions, so
there would be some free processing power for those stuff to be
created.
To implement this, I thought of doing this in a seperate, low-priority
thread which would just invoke Kernel.Get<>() for each Type and name
which are going to be called later. This would front-load some of the
initialization stuff and if I am correct, Ninject (I am talking about
Version 2) should handle the concurrency issues correctly.
I looked through the source code and found that the Resolve()-Method
requests a lock on the Binding which is to be resolved. Am I correct
that this is thread safe for each Service and Name and thus my pre-
load mechanism should work correctly regarding concurrent Resolve()-
calls to the same Kernel (I only have one in my application)?
So far it seems to work, but multithreading problems are hard to test,
so I would like get some feedback on this.
Best regards,
Tim
I would like to implement a pre-loading mechanism in my application.
When the user enters certain areas, I know for certain that he will
step through a series of Windows Forms (and some associated objects).
Luckily, there are some initial network communication actions, so
there would be some free processing power for those stuff to be
created.
To implement this, I thought of doing this in a seperate, low-priority
thread which would just invoke Kernel.Get<>() for each Type and name
which are going to be called later. This would front-load some of the
initialization stuff and if I am correct, Ninject (I am talking about
Version 2) should handle the concurrency issues correctly.
I looked through the source code and found that the Resolve()-Method
requests a lock on the Binding which is to be resolved. Am I correct
that this is thread safe for each Service and Name and thus my pre-
load mechanism should work correctly regarding concurrent Resolve()-
calls to the same Kernel (I only have one in my application)?
So far it seems to work, but multithreading problems are hard to test,
so I would like get some feedback on this.
Best regards,
Tim
Ian Davis
Nov 26, 2009, 9:21:05 AM11/26/09
to nin...@googlegroups.com
The key is the lock on the binding. Requests that use the same binding will be threadsafe. But, you may have many bindings for a particular interface, in which case you would have to perform your own synchronization.
--
Ian Davis
http://disassembla.net
--
You received this message because you are subscribed to the Google Groups "ninject" group.
To post to this group, send email to nin...@googlegroups.com.
To unsubscribe from this group, send email to ninject+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ninject?hl=en.
--
Ian Davis
http://disassembla.net
TWischmeier
Nov 26, 2009, 10:11:39 AM11/26/09
to ninject
Thanks, that is the information I was looking for (and an error source
I wouldn't have found quickly). Luckily I do have a central class for
caching Forms which makes implementing locking and preloading quite
easy.
Out curiousity: what parameters do uniquely define a Binding (the one
that is being locked)? Is it just the service, or is it service + name
or something else?
For example, my definitions for a module look like this:
Bind<INavigationForm>().To<AConcreteForm>().Named("ACertainState");
Bind<INavigationForm>().To<AnotherConcreteForm>().Named
("AnotherState");
Are concurrent calls to Kernel.Get<INavigationForm>("ACertainState")
and Kernel.Get<INavigationForm>("AnotherState") safe, or is this
exactly what you explained in your answer?
On 26 Nov., 15:21, Ian Davis <ian.f.da...@gmail.com> wrote:
> The key is the lock on the binding. Requests that use the same binding will
> be threadsafe. But, you may have many bindings for a particular interface,
> in which case you would have to perform your own synchronization.
>
> On Thu, Nov 26, 2009 at 5:39 AM, TWischmeier
> <tim.wischme...@googlemail.com>wrote:
> > ninject+u...@googlegroups.com<ninject%2Bunsu...@googlegroups.com>
> > .
I wouldn't have found quickly). Luckily I do have a central class for
caching Forms which makes implementing locking and preloading quite
easy.
Out curiousity: what parameters do uniquely define a Binding (the one
that is being locked)? Is it just the service, or is it service + name
or something else?
For example, my definitions for a module look like this:
Bind<INavigationForm>().To<AConcreteForm>().Named("ACertainState");
Bind<INavigationForm>().To<AnotherConcreteForm>().Named
("AnotherState");
Are concurrent calls to Kernel.Get<INavigationForm>("ACertainState")
and Kernel.Get<INavigationForm>("AnotherState") safe, or is this
exactly what you explained in your answer?
On 26 Nov., 15:21, Ian Davis <ian.f.da...@gmail.com> wrote:
> The key is the lock on the binding. Requests that use the same binding will
> be threadsafe. But, you may have many bindings for a particular interface,
> in which case you would have to perform your own synchronization.
>
> On Thu, Nov 26, 2009 at 5:39 AM, TWischmeier
> > .
Ian Davis
Nov 26, 2009, 1:03:45 PM11/26/09
to nin...@googlegroups.com
Each call to .Bind creates a new binding.
To unsubscribe from this group, send email to ninject+u...@googlegroups.com.
TWischmeier
Nov 30, 2009, 6:20:55 AM11/30/09
to ninject
To follow up on this:
"Preloading" the resolutions works perfectly and expecially on a
mobile device the "experienced performance" does increase.
Unfortunately, it is not possible to preload Windows Forms. They have
to be created in the same thread the main message pump was started
(which usually is the main thread), and obviously there is no point in
doing preload work in your main thread. There also is no possibility
of creating the form in on thread an moving / appending it to another.
But if the application is divided into layers properly, your logic and
your data layers can be preloaded independently, which still enables
you to do significant preload work.
On a side note: should you spend two or more days looking for the
source of your memory leak, check your binding scopes...
On 26 Nov., 19:03, Ian Davis <ian.f.da...@gmail.com> wrote:
> Each call to .Bind creates a new binding.
>
> On Thu, Nov 26, 2009 at 7:11 AM, TWischmeier
> <tim.wischme...@googlemail.com>wrote:
> > <ninject%2Bunsu...@googlegroups.com<ninject%252Buns...@googlegroups.com>
"Preloading" the resolutions works perfectly and expecially on a
mobile device the "experienced performance" does increase.
Unfortunately, it is not possible to preload Windows Forms. They have
to be created in the same thread the main message pump was started
(which usually is the main thread), and obviously there is no point in
doing preload work in your main thread. There also is no possibility
of creating the form in on thread an moving / appending it to another.
But if the application is divided into layers properly, your logic and
your data layers can be preloaded independently, which still enables
you to do significant preload work.
On a side note: should you spend two or more days looking for the
source of your memory leak, check your binding scopes...
On 26 Nov., 19:03, Ian Davis <ian.f.da...@gmail.com> wrote:
> Each call to .Bind creates a new binding.
>
> On Thu, Nov 26, 2009 at 7:11 AM, TWischmeier
Reply all
Reply to author
Forward
0 new messages