CODEWITHSUNDEEP
.netmultithreadingqueue
zerkms
zerkms

Reputation: 255155

Threads, queue and workflow

(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.

Upvotes: 1

Views: 170

Answers (2)

Christopher Hunt
Christopher Hunt

Reputation: 2081

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.

Upvotes: 0

Ian Mercer
Ian Mercer

Reputation: 39307

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.

Upvotes: 3

Related Questions