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