views:

55

answers:

2

(As justification - I've never worked with threads so the description below is just an idea I want you to criticize)

The task overview:
- There is a list of some Objects
- We need to check if the object has been changed in some way
- If it was changed - apply some logic (for example - show notify).

This is how I think it should be implemented:

We create timer, triggered each minute, which traverse the Objects list and find the Objects that needs to be checked. After that we add that Object (or to be specific - some task object, that contains Object and task description: to check if it was updated) to the Queue.

Worker (some thread in thread pool) waits until something is added to the Queue, and after it is happened - it takes the Task and processes it: checks if Object was changed. If so - it adds another task, notification one. And now another worker, that processes notification tasks will handle this task, if necessary.

So, is it totally wrong idea? What can be improved or changed here?

UPD: according to first answer: Object depends on some repote resource, and "change" means that some remote data changed (or changed in some specific manner). So this cannot be solved with INotifyPropertyChanged.

+3  A: 

If these 'objects' are .NET objects why would you poll them? Why not implement something like the INotifyPropertyChanged interface instead and have a proper, immediate notification of changes?

Otherwise, if they are in fact external objects of some kind that can only be tested by polling, then a timer that fires off an event that then polls each object and Invokes the notification back to the UI thread is probably sufficient, or if you want the timer event to finish quickly (e.g. so it can respond to another event immediately), fire off a Task to go check each object and notify the UI (using an Invoke) if it has changed.

There's no need to queue up each individual object and process them separately (is there??), nor any requirement to process them in parallel, so a simple loop over them in the worker thread (or Task) would seem sufficient.

Hightechrider
There is - because the "checking" operation may be "long", due to Object is related to some remote 3rd party resource.
zerkms
"nor any requirement to process them in parallel, so a simple loop over them in the worker thread" - in this case all logic of when to do work and what work to do - is in one place. And in question i've described scenario when they are totally separated by queue: one part is make a decision of updating, another - make a decision of processing, and Queue between them.
zerkms
I would say that this answer is more or less right on--loop over the objects, fire a Task to go poll each object, report back to UI thread. That way you don't have to worry about taking care of managing polling threads, etc.
B.R.
(oh, then i did not understand that, terrible english) well, then this answer in simply is: to loop over collection and start thread for each Object that need to be checked?
zerkms
You can go either way - fire off a Task per object (if you want to process them in parallel) OR fire off one task that processes them sequentially. Since you are only polling once a minute I can't imagine why you'd suddenly want to process them in parallel though which is why I actually suggested a simple loop running in a task. As to separating the poll step from the notification step, that seems unnecessarily complicated - you have a thread, keep going on it if it's a purely sequential operation that you want to do next.
Hightechrider
Yep, thanks, seems I get what you mean ;-)
zerkms
A: 

I'm just wondering if you might consider a queue for pending tasks. Any task objects that are pushed to this queue are therefore waiting to be processed. In your worker thread you block on the queue until an item becomes available. You might have multiple worker threads doing this if you'd like some parallelism.

You might also have a list of tasks showing which are in progress, and another list showing which are complete.

I'm not a C# programmer but in Java I would look to using an implementation of the BlockingQueue interface.

Christopher Hunt
Nope, queue in my scenario is for tasks should be processed as far as any worker is available for performing.
zerkms