Which Async. Pattern should I be using?

[Dog Ears]

I've got a windows form that monitors the status of employees [location/work
status etc] it polls a database every 2 seconds to fetch updates [index on
history table with 'LastUpdate' Datetime field] then update a underlying
dataset bound to a grid using Invoke to marshal to the gui thread.

What pattern should I be using now I'm upgrading to .net 2.0? APM, async
delegates and BeginInvoke or Thread.Start etc...?

Should I be creating a single thread manulally (or using threadpool) and and
setting the polling on an internal loop with a Thread.Sleep(20 00) ?

Any advice on what approach I should take would be very much appreciated.

Many thanks,
Graeme.

[=?Utf-8?B?Q2lhcmFuIE8nJ0Rvbm5lbGw=?=]

RE: Which Async. Pattern should I be using?

You could use a System.Timers.T imer which fires the Elasped event on a thread
pool thread. At the start of the event handler, stop the timer, then do the
work, the restart the timer.

You would still need to invoke to the UI thread as it fires on a pool thread.

HTH

--
Ciaran O''Donnell

http://wannabedeveloper.spaces.live.com

"Dog Ears" wrote:

I've got a windows form that monitors the status of employees [location/work
status etc] it polls a database every 2 seconds to fetch updates [index on
history table with 'LastUpdate' Datetime field] then update a underlying
dataset bound to a grid using Invoke to marshal to the gui thread.
>
What pattern should I be using now I'm upgrading to .net 2.0? APM, async
delegates and BeginInvoke or Thread.Start etc...?
>
Should I be creating a single thread manulally (or using threadpool) and and
setting the polling on an internal loop with a Thread.Sleep(20 00) ?
>
Any advice on what approach I should take would be very much appreciated.
>
Many thanks,
Graeme.
>
>
>

[Dog Ears]

Re: Which Async. Pattern should I be using?

Many thanks for your reply, just as I posted I stumbed across the timer
class (CLR via C#, J.Richter) it does seem a good option...

But my only concern is that most of the async code/logic etc is currently in
the form, i'd like to encapsulate it into the "monitoring " class, so that it
performs the asynchronous update 'internally' i'm just a bit concerned about
the updates. Maybe this would over complicate the design?

Regards,
Graeme.


"Ciaran O''Donnell" <CiaranODonnell @discussions.mi crosoft.comwrot e in
message news:10FA4D10-FA27-4E5F-BC40-B544399AFC14@mi crosoft.com...

You could use a System.Timers.T imer which fires the Elasped event on a
thread
pool thread. At the start of the event handler, stop the timer, then do
the
work, the restart the timer.
>
You would still need to invoke to the UI thread as it fires on a pool
thread.
>
HTH
>
--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com

[Dog Ears]

Re: Which Async. Pattern should I be using?

If i have a collection that is being updated by another thread, and a Gui
control (grid) is bound to that collection, how do i update the collection
from the other thread, as the collection hasn't got an 'InvokeRequired '
property, do i just need to concentrate on Synchronisation and not worry
about 'invoke' to the gui thread?


"Dog Ears" <graeme.stow@re verse.net.virgi nwrote in message
news:MKSdnRxv1I 1GlIva4p2dnAA@p ipex.net...

Many thanks for your reply, just as I posted I stumbed across the timer
class (CLR via C#, J.Richter) it does seem a good option...
>
But my only concern is that most of the async code/logic etc is currently
in the form, i'd like to encapsulate it into the "monitoring " class, so
that it performs the asynchronous update 'internally' i'm just a bit
concerned about the updates. Maybe this would over complicate the design?
>
Regards,
Graeme.
>
>
"Ciaran O''Donnell" <CiaranODonnell @discussions.mi crosoft.comwrot e in
message news:10FA4D10-FA27-4E5F-BC40-B544399AFC14@mi crosoft.com...

>You could use a System.Timers.T imer which fires the Elasped event on a
>thread
>pool thread. At the start of the event handler, stop the timer, then do
>the
>work, the restart the timer.
>>
>You would still need to invoke to the UI thread as it fires on a pool
>thread.
>>
>HTH
>>
>--
>Ciaran O''Donnell
>http://wannabedeveloper.spaces.live.com

>
>

[Peter Duniho]

Re: Which Async. Pattern should I be using?

Dog Ears wrote:

If i have a collection that is being updated by another thread, and a Gui
control (grid) is bound to that collection, how do i update the collection
from the other thread, as the collection hasn't got an 'InvokeRequired '
property, do i just need to concentrate on Synchronisation and not worry
about 'invoke' to the gui thread?

Yes. Invoke is required for things that involve window messages, but
for other data objects not connected to those, you just need ordinary
synchronization .

That said, sometimes using Invoke or BeginInvoke is one of the simplest
ways to synchronize other data objects. You'd have to have some Control
instance that the data object is tied to (either because it's an actual
member of the Control instance, or because of some design
characteristic) , so that you can use that Control's Invoke or
BeginInvoke method. But other than that, it can be a useful technique.

Pete

[Nicholas Paldino [.NET/C# MVP]]

Re: Which Async. Pattern should I be using?

This is not completely true. If the collection class implements any of
the notification mechanisms that data binding supports (the
<property>Chang ed event pattern, implementation of the
INotifyCollecti onChanged or INotifyProperty Changed interfaces), then you
have to make sure that you make changes to your collection on the UI thread,
so that whatever is bound to it won't throw an exception when the
notification event from the collection triggers a UI change.

I'm assuming here, of course, that your "yes" answer is in response to
the question about concentrating solely on synchronization , and not on
calling Invoke.

--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13hchhhjbo s7tbd@corp.supe rnews.com...

Dog Ears wrote:

>If i have a collection that is being updated by another thread, and a Gui
>control (grid) is bound to that collection, how do i update the
>collection from the other thread, as the collection hasn't got an
>'InvokeRequire d' property, do i just need to concentrate on
>Synchronisatio n and not worry about 'invoke' to the gui thread?

>
Yes. Invoke is required for things that involve window messages, but for
other data objects not connected to those, you just need ordinary
synchronization .
>
That said, sometimes using Invoke or BeginInvoke is one of the simplest
ways to synchronize other data objects. You'd have to have some Control
instance that the data object is tied to (either because it's an actual
member of the Control instance, or because of some design characteristic) ,
so that you can use that Control's Invoke or BeginInvoke method. But
other than that, it can be a useful technique.
>
Pete

[Peter Duniho]

Re: Which Async. Pattern should I be using?

Nicholas Paldino [.NET/C# MVP] wrote:

This is not completely true. If the collection class implements any of
the notification mechanisms that data binding supports (the
<property>Chang ed event pattern, implementation of the
INotifyCollecti onChanged or INotifyProperty Changed interfaces), then you
have to make sure that you make changes to your collection on the UI thread,
so that whatever is bound to it won't throw an exception when the
notification event from the collection triggers a UI change.

Thank you for the clarification.

My answer does of course assume that one is interacting with the
collection class itself only. I agree that if you have somehow
connected the connection class to a UI control, that the thread issues
are introduced.

But IMHO those aren't a characteristic of the collection itself; that
has more to do with what's bound to the property of the collection. You
could just as easily have the property bound to something without such a
requirement AFAIK. For example, simply subscribing to a
<property>Chang ed event doesn't require Invoke; it's only when the event
handler itself winds up doing something with a Control that that would
come up.

I assume the same sort of thing is true for the INotify... interfaces,
but I'm not that familiar with them so I won't make a claim regarding those.

IMHO, the key here is understanding how one is actually using the
collection, and handling cross-thread UI issues via Invoke if
appropriate. A collection class in and of itself has no such issues.

Pete

[Nicholas Paldino [.NET/C# MVP]]

Re: Which Async. Pattern should I be using?

I agree, I was just pointing it out since "Dog Ears" specifically stated
that his collection was bound to a GUI control.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13hcodqh54 m5491@corp.supe rnews.com...

Nicholas Paldino [.NET/C# MVP] wrote:

> This is not completely true. If the collection class implements any
>of the notification mechanisms that data binding supports (the
><property>Chan ged event pattern, implementation of the
>INotifyCollect ionChanged or INotifyProperty Changed interfaces), then you
>have to make sure that you make changes to your collection on the UI
>thread, so that whatever is bound to it won't throw an exception when the
>notification event from the collection triggers a UI change.

>
Thank you for the clarification.
>
My answer does of course assume that one is interacting with the
collection class itself only. I agree that if you have somehow connected
the connection class to a UI control, that the thread issues are
introduced.
>
But IMHO those aren't a characteristic of the collection itself; that has
more to do with what's bound to the property of the collection. You could
just as easily have the property bound to something without such a
requirement AFAIK. For example, simply subscribing to a <property>Chang ed
event doesn't require Invoke; it's only when the event handler itself
winds up doing something with a Control that that would come up.
>
I assume the same sort of thing is true for the INotify... interfaces, but
I'm not that familiar with them so I won't make a claim regarding those.
>
IMHO, the key here is understanding how one is actually using the
collection, and handling cross-thread UI issues via Invoke if appropriate.
A collection class in and of itself has no such issues.
>
Pete

[Peter Duniho]

Re: Which Async. Pattern should I be using?

Nicholas Paldino [.NET/C# MVP] wrote:

I agree, I was just pointing it out since "Dog Ears" specifically stated
that his collection was bound to a GUI control.

Ah, yes. Somehow I managed to overlook that, in spite of it being
mentioned more than once.

So, I guess my suggestion that using Invoke or BeginInvoke is useful for
synchronization is more than just something that might be useful for
convenience. It might actually be the best way to solve the
synchronization issues, just as you suggest. :)

Pete

[Dog Ears]

Re: Which Async. Pattern should I be using?

so in a collection object that asynchronously updates itself internally, how
would I would i update the collection (from within) and marshal the calls
across to the gui thread?

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13hcq8djvp tfhf7@corp.supe rnews.com...

Nicholas Paldino [.NET/C# MVP] wrote:

> I agree, I was just pointing it out since "Dog Ears" specifically
>stated that his collection was bound to a GUI control.

>
Ah, yes. Somehow I managed to overlook that, in spite of it being
mentioned more than once.
>
So, I guess my suggestion that using Invoke or BeginInvoke is useful for
synchronization is more than just something that might be useful for
convenience. It might actually be the best way to solve the
synchronization issues, just as you suggest. :)
>
Pete

[Chris Mullins [MVP - C#]]

Re: Which Async. Pattern should I be using?

The collection itself would be updated based on the async calls that come
in.

The collection would then raise events ("User Added", "User Offline") on
either the IOCP thread the async call came in on, or on the system
threadpool. Whoever handles the event (aka: The GUI) would need to do the
control.invoke to get off the IOCP thread, and back to the GUI thread.

This means the collection would need to be thread safe, and the GUI would
need to know that any events it receives from the collection need to be
marshalled prior to doing anything fun with.

Alternativly, you could take the approach of the collection having a control
property on it, that is set by the GUI. When an async callback happens, the
list updates itself, marshalls over to the right thread (using the
control.BeginIn voke), then raises the event.

--
Chris Mullins


"Dog Ears" <graeme.stow@re verse.net.virgi nwrote in message
news:vbydnYGYdc BMAIvanZ2dneKdn ZydnZ2d@pipex.n et...

so in a collection object that asynchronously updates itself internally,
how would I would i update the collection (from within) and marshal the
calls across to the gui thread?
>
"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13hcq8djvp tfhf7@corp.supe rnews.com...

>Nicholas Paldino [.NET/C# MVP] wrote:

>> I agree, I was just pointing it out since "Dog Ears" specifically
>>stated that his collection was bound to a GUI control.

>>
>Ah, yes. Somehow I managed to overlook that, in spite of it being
>mentioned more than once.
>>
>So, I guess my suggestion that using Invoke or BeginInvoke is useful for
>synchronizatio n is more than just something that might be useful for
>convenience. It might actually be the best way to solve the
>synchronizatio n issues, just as you suggest. :)
>>
>Pete

>
>

[Dog Ears]

Re: Which Async. Pattern should I be using?

The problem is the events are standard binding interface events like
INotifyProperty Changed.Propert yChanged, and the events are handled by
standard control, wich isn't going to be checking the InvokeRequired, i
guess the simple answer is do all the async stuff from the form?

Regards,
Graeme.

"Chris Mullins [MVP - C#]" <cmullins@yahoo .comwrote in message
news:e5%23XtlRE IHA.4028@TK2MSF TNGP05.phx.gbl. ..

The collection itself would be updated based on the async calls that come
in.
>
The collection would then raise events ("User Added", "User Offline") on
either the IOCP thread the async call came in on, or on the system
threadpool. Whoever handles the event (aka: The GUI) would need to do the
control.invoke to get off the IOCP thread, and back to the GUI thread.
>
This means the collection would need to be thread safe, and the GUI would
need to know that any events it receives from the collection need to be
marshalled prior to doing anything fun with.
>
Alternativly, you could take the approach of the collection having a
control property on it, that is set by the GUI. When an async callback
happens, the list updates itself, marshalls over to the right thread
(using the control.BeginIn voke), then raises the event.
>
--
Chris Mullins
>
>
"Dog Ears" <graeme.stow@re verse.net.virgi nwrote in message
news:vbydnYGYdc BMAIvanZ2dneKdn ZydnZ2d@pipex.n et...

>so in a collection object that asynchronously updates itself internally,
>how would I would i update the collection (from within) and marshal the
>calls across to the gui thread?
>>
>"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
>news:13hcq8djv ptfhf7@corp.sup ernews.com...

>>Nicholas Paldino [.NET/C# MVP] wrote:
>>> I agree, I was just pointing it out since "Dog Ears" specifically
>>>stated that his collection was bound to a GUI control.
>>>
>>Ah, yes. Somehow I managed to overlook that, in spite of it being
>>mentioned more than once.
>>>
>>So, I guess my suggestion that using Invoke or BeginInvoke is useful for
>>synchronizati on is more than just something that might be useful for
>>convenience . It might actually be the best way to solve the
>>synchronizati on issues, just as you suggest. :)
>>>
>>Pete

>>
>>

>
>

[Peter Duniho]

Re: Which Async. Pattern should I be using?

Dog Ears wrote:

The problem is the events are standard binding interface events like
INotifyProperty Changed.Propert yChanged, and the events are handled by
standard control, wich isn't going to be checking the InvokeRequired, i
guess the simple answer is do all the async stuff from the form?

Well, IMHO the simplest means is to do what I suggested originally.
That, make sure you've got a Control that is associated in some specific
way with the collection and use that Control's Invoke for handling
synchronization .

The way it would work is that whatever asynchronously would update the
collection, would instead use Invoke or BeginInvoke to call a method on
the Control that "owns" the collection to actually do the update on the
collection. That method will execute on the correct thread, and as long
as you only use this mechanism for updating the collection it will
_also_ have the effect of synchronizing access to the collection, since
only that one thread will ever actually modify the collection.

If you don't have a Control that naturally correlates on a one-to-one
basis with the collection, then an alternative is to use an
AsyncOperation, which can also be tied to a specific thread (including
the main GUI thread where everything else is happening). I don't recall
the details, as it's been a year or so since I was playing with it. But
it's an alternative that I know worked for me at the time.

Pete

[Dog Ears]

Re: Which Async. Pattern should I be using?

Well, IMHO the simplest means is to do what I suggested originally.
That, make sure you've got a Control that is associated in some specific
way with the collection and use that Control's Invoke for handling
synchronization .

I'm confused, if i want to creat the class to handle it's own async fetching
from the DB how can i link it to a Control? should i inherit from Control
and then before doing updates to the collection check for InvokeRequired,
isn't there a way to do this without requireing the Control as a base
classs?

>
The way it would work is that whatever asynchronously would update the
collection, would instead use Invoke or BeginInvoke to call a method on
the Control that "owns" the collection to actually do the update on the
collection. That method will execute on the correct thread, and as long
as you only use this mechanism for updating the collection it will _also_
have the effect of synchronizing access to the collection, since only that
one thread will ever actually modify the collection.
>
If you don't have a Control that naturally correlates on a one-to-one
basis with the collection, then an alternative is to use an
AsyncOperation, which can also be tied to a specific thread (including the
main GUI thread where everything else is happening). I don't recall the
details, as it's been a year or so since I was playing with it. But it's
an alternative that I know worked for me at the time.

Is this AsyncOperation used in the "Event Based Async Pattern" mentioned in
the MSDN docs? I've implemented a working prototype of this and it seems to
be working.

Pete

Cheers Pete, i'll keep chipping away. thankyou.
Graeme.