Thread related design advice please

[Bishman]

Hi,

I have a form application that needs to query a DB at a set timed interval
and then refresh the form with values received from the DB. Simple enough.

My design releated questions are ....

Should I create a worker thread that encapsulates a timer, (which I believe
will also create a seperate thread when the timer fires) , or should I
create a timer that creates a new thread when it fires ? Or neither ?

Which sort of timer should I use. "System.Timers.Timer" or
"System.Windows.Forms.Timer"

I was going to 'place' the results of the DB query into a queue of some sort
that can then be retrieved at a set interval ( another timer ? ) and display
them on the form. How do I make this queue threadsafe ?

Some general design pointers would be appreciated.

Thanks.
Jon.

 

[Bishman]

....also I have just noticed the 'System.Threading.Timer' !

 

[Bishman]

Could I use two forms timers, one to handle the DB query and one to handle
the UI update ?

If I take this approach I would assume I would still need to perform some
thread safety around the saving and retrieving of records ?

ie Thread 1 updates retrieves DB records and saves them away in the 'queue',
thread two reads from the 'queue' at set intervals and updates the ui ?

.........confused......

Jon

 

[Brian Gideon]

Jon,

There are several acceptable options. I would probably use the
System.Timers.Timer to execute the DB code. After the DB code ran I
would call Control.Invoke to marshal a delegate onto the UI thread to
update the form with the results. Avoid setting the
SynchronizingObject property on the Timer because you want the DB code
to execute off the UI thread. That way the UI remains responsive.

The caveat here is that System.Timers.Timer will use a ThreadPool
thread when SynchronizingObject is null. I typically recommend not
putting long running tasks on the ThreadPool, but I'm guilty of bending
the rules sometimes myself.

I think it would be fine if you chose to create and use a dedicate
thread that uses a Thread.Sleep (or other waiting mechanism) to execute
the DB code on an interval as well. If you have a worker thread
dedicated for the task then there's no need for a timer. Again, make
sure to use Control.Invoke to update the form.

As for the queue question, it's probably not needed. The Windows
message loop running on the UI thread is already implemented with a
queue. A message is sent to it already with Control.Invoke.

Brian

 

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

Bishman,

I would use the timer in the System.Timers namespace. When the event
fires, I would perform the fetching of the data (since the callback will be
on a non-ui thread anyways), and then update the UI through a call to
Invoke.

Hope this helps.

 

[Bishman]

Thanks for that.

Can I update a Queue in the same way ?

Bishman,

I would use the timer in the System.Timers namespace. When the event
fires, I would perform the fetching of the data (since the callback will
be on a non-ui thread anyways), and then update the UI through a call to
Invoke.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I have a form application that needs to query a DB at a set timed
interval and then refresh the form with values received from the DB.
Simple enough.

My design releated questions are ....

Should I create a worker thread that encapsulates a timer, (which I
believe will also create a seperate thread when the timer fires) , or
should I create a timer that creates a new thread when it fires ? Or
neither ?

Which sort of timer should I use. "System.Timers.Timer" or
"System.Windows.Forms.Timer"

I was going to 'place' the results of the DB query into a queue of some
sort that can then be retrieved at a set interval ( another timer ? ) and
display them on the form. How do I make this queue threadsafe ?

Some general design pointers would be appreciated.

Thanks.
Jon.

 

[Bishman]

Brian,

Many thanks for the reply.

I will try and digest what all that means then give it a go !

Just two points. Can you explain a little more about what you mean by "Avoid
setting the SynchronizingObject property on the Timer". Do you mean attach
the synchronizing object to the UI Thread not the Timer Thread ? (If that
makes sense ....).

Also I was going to use a queue as the UI will display the results of the
each record selected for a set time, then move onto the next record and so
on. That way the worker thead can continue to pull back various records at
odd intervals, but the UI thread can display each record for a set period,
then move on.

I think this will work.

 

[Brian Gideon]

Brian,

Many thanks for the reply.

I will try and digest what all that means then give it a go !

Just two points. Can you explain a little more about what you mean by "Avoid
setting the SynchronizingObject property on the Timer". Do you mean attach
the synchronizing object to the UI Thread not the Timer Thread ? (If that
makes sense ....).

SynchronizingObject accepts an ISynchronizeInvoke object. Forms and
controls implement this interface. When the property is set to a form
or control from your application the timer will automatically marshal
the execution of the Elapsed event onto the UI thread. If you did that
then you DB code wouldn't be executed on a separate thread. Think of
it this this way. The Elapsed event will run on the same thread
hosting the SynchronizingObject which is usually a Form or Control. If
the SynchronizingObject is null the Elapsed event will run a thread
from the ThreadPool.

Also I was going to use a queue as the UI will display the results of the
each record selected for a set time, then move onto the next record and so
on. That way the worker thead can continue to pull back various records at
odd intervals, but the UI thread can display each record for a set period,
then move on.

Okay, I think I understand what you're saying. The worker or timer
thread will be enqueueing records into the queue and the UI will
dequeue them. And you want it that way because the enqueueing interval
may be different than the dequeueing interval. Is that right?

 

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

Care to elaborate on what you mean by a Queue?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Thanks for that.

Can I update a Queue in the same way ?

Bishman,

I would use the timer in the System.Timers namespace. When the event
fires, I would perform the fetching of the data (since the callback will
be on a non-ui thread anyways), and then update the UI through a call to
Invoke.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I have a form application that needs to query a DB at a set timed
interval and then refresh the form with values received from the DB.
Simple enough.

My design releated questions are ....

Should I create a worker thread that encapsulates a timer, (which I
believe will also create a seperate thread when the timer fires) , or
should I create a timer that creates a new thread when it fires ? Or
neither ?

Which sort of timer should I use. "System.Timers.Timer" or
"System.Windows.Forms.Timer"

I was going to 'place' the results of the DB query into a queue of some
sort that can then be retrieved at a set interval ( another timer ? )
and display them on the form. How do I make this queue threadsafe ?

Some general design pointers would be appreciated.

Thanks.
Jon.

 

[Bishman]

"System.Collections" namespace - "Queue" Class .

Care to elaborate on what you mean by a Queue?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Thanks for that.

Can I update a Queue in the same way ?

Bishman,

I would use the timer in the System.Timers namespace. When the event
fires, I would perform the fetching of the data (since the callback will
be on a non-ui thread anyways), and then update the UI through a call to
Invoke.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I have a form application that needs to query a DB at a set timed
interval and then refresh the form with values received from the DB.
Simple enough.

My design releated questions are ....

Should I create a worker thread that encapsulates a timer, (which I
believe will also create a seperate thread when the timer fires) , or
should I create a timer that creates a new thread when it fires ? Or
neither ?

Which sort of timer should I use. "System.Timers.Timer" or
"System.Windows.Forms.Timer"

I was going to 'place' the results of the DB query into a queue of some
sort that can then be retrieved at a set interval ( another timer ? )
and display them on the form. How do I make this queue threadsafe ?

Some general design pointers would be appreciated.

Thanks.
Jon.

 

[Bishman]

OK - I think I get that ! Thanks very much.

Jon.