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(2000) ?
Any advice on what approach I should take would be very much appreciated.
Many thanks,
Graeme.
13  1954 
You could use a System.Timers.Timer 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(2000) ?
Any advice on what approach I should take would be very much appreciated.
Many thanks,
Graeme.
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" <Ci************@discussions.microsoft.comwrote in
message news:10**********************************@microsof t.com...
You could use a System.Timers.Timer 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
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" <gr*********@reverse.net.virginwrote in message
news:MK*********************@pipex.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" <Ci************@discussions.microsoft.comwrote in
message news:10**********************************@microsof t.com...
>You could use a System.Timers.Timer 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:
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
This is not completely true. If the collection class implements any of
the notification mechanisms that data binding supports (the
<property>Changed event pattern, implementation of the
INotifyCollectionChanged or INotifyPropertyChanged 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]
- mv*@spam.guard.caspershouse.com
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.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
'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] wrote:
This is not completely true. If the collection class implements any of
the notification mechanisms that data binding supports (the
<property>Changed event pattern, implementation of the
INotifyCollectionChanged or INotifyPropertyChanged 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>Changed 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
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]
- mv*@spam.guard.caspershouse.com
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.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>Changed event pattern, implementation of the
INotifyCollectionChanged or INotifyPropertyChanged 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>Changed
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] 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
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" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.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
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.BeginInvoke), then raises the event.
--
Chris Mullins
"Dog Ears" <gr*********@reverse.net.virginwrote in message
news:vb******************************@pipex.net...
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" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.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
The problem is the events are standard binding interface events like
INotifyPropertyChanged.PropertyChanged, 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#]" <cm******@yahoo.comwrote in message
news:e5****************@TK2MSFTNGP05.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.BeginInvoke), then raises the event.
--
Chris Mullins
"Dog Ears" <gr*********@reverse.net.virginwrote in message
news:vb******************************@pipex.net...
>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" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.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
Dog Ears wrote:
The problem is the events are standard binding interface events like
INotifyPropertyChanged.PropertyChanged, 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
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Joshua Coady |
last post by:
I am writing a class that includes several async methods following the
BeginXxx, EndXxx pattern. Some of these methods will call methods in the
framework such as Stream.Read or Socket.Send. Do I...
|
by: Passynkov, Vadim |
last post by:
I am using Asynchronous Query Processing interface from libpq library.
And I got some strange results on Solaris
My test select query is 'SELECT * from pg_user;'
and I use select system...
|
by: Dan Diephouse |
last post by:
I am working on developing a series of web services around the jabber
protocol. I have written the necessary soap over jabber code on the
server side (java) and am now working on the client side...
|
by: Chuck |
last post by:
Hello,
I am having trouble loading the returned XML from a Webservice into my XSL.
Any suggestions would be appreciated.
' Build custom HTTP header
xmlServerHttp.open "POST",...
|
by: Frankie |
last post by:
It appears that System.Random would provide an acceptable means through
which to generate a unique value used to identify multiple/concurrent
asynchronous tasks.
The usage of the value under...
|
by: Paul Hadfield |
last post by:
Hi,
From reading various articles on scalability issues, I understand that there
is only a finite number of ASP.NET worker threads and any long running task
within ASP.NET should be fired off on...
|
by: =?Utf-8?B?RGF2ZQ==?= |
last post by:
Hi, I'm trying to implement asynch web service calls in .NET 2.0
However, when I created a ClassLibrary project, the WebReference I added
doesn't include the Begin/End methods (as in 1.1) but...
|
by: robert112 |
last post by:
Question... Can one not use ThreadPool.QueueUserWorkItem with an
anonymous method like so:
ThreadPool.QueueUserWorkItem(delegate
{
//perform IO bound operation.
});
Why did the asp.net team...
|
by: APA |
last post by:
I've seen the MS sample async web request pattern and I ask is it really async if it is using a ManualResetEvent and setting WaitOne()? The
ManualResetEvent object is being declared as a static...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
