threads, la file d'attente et flux de travail

Question

(Comme justification - je n'ai jamais travaillé avec des fils de sorte que la description ci-dessous est juste une idée que je veux que vous critiquez)

La vue d'ensemble des tâches:
- Il y a une liste de certains Objets
- Nous devons vérifier si l'objet a été modifié d'une manière ou d'une autre
- Si elle a été modifiée - appliquez une certaine logique (par exemple - show notify).

Voilà comment je pense qu'il devrait être mis en œuvre:

Nous créons minuterie, chaque minute a déclenché, qui traversent la liste des objets et trouver les objets qui doivent être vérifiés. Après cela, nous ajoutons cet objet (ou pour être spécifique - un objet de tâche, qui contient la description de l'objet et de la tâche: pour vérifier s'il a été mis à jour) dans la file d'attente. Travailleur (un thread dans le pool de threads) attend jusqu'à ce que quelque chose soit ajouté à la file d'attente, et après qu'il est arrivé - il prend la tâche et la traite: vérifie si l'objet a été changé. Si c'est le cas - il ajoute une autre tâche, notification une. Et maintenant un autre worker, qui traite les tâches de notification, va gérer cette tâche, si nécessaire.

Alors, est-ce totalement fausse idée? Qu'est-ce qui peut être amélioré ou changé ici?

UPD: selon la première réponse: L'objet dépend d'une ressource repote, et "change" signifie que certaines données distantes ont changé (ou ont changé d'une manière spécifique). Donc, cela ne peut pas être résolu avec INotifyPropertyChanged.

Answer 1

Si ces 'objets' sont des objets .NET, pourquoi les interroger? Pourquoi ne pas implémenter quelque chose comme l'interface INotifyPropertyChanged à la place et avoir une notification immédiate et appropriée des changements?

Sinon, si elles sont en fait des objets extérieurs de quelque sorte que peut ne être testés par sondages, puis une minuterie qui déclenche au large un événement puis interroge chaque objet et Invoque la notification au thread d'interface utilisateur est probablement suffisant, ou si vous souhaitez que l'événement timer se termine rapidement (par exemple pour qu'il puisse répondre immédiatement à un autre événement), déclenchez un Task pour vérifier chaque objet et notifiez l'interface utilisateur (à l'aide d'un appel) s'il a été modifié. Il n'est pas nécessaire de mettre en file d'attente chaque objet individuel et de les traiter séparément (existe-t-il?), Ni de les traiter en parallèle, donc une simple boucle sur le thread de travail (ou Task) semble suffisante .

Answer 2

Je me demandais si vous pourriez envisager une file d'attente pour les tâches en attente. Tous les objets de tâche qui sont poussés vers cette file attendent donc d'être traités. Dans votre thread de travail, vous bloquez dans la file d'attente jusqu'à ce qu'un élément devienne disponible. Vous pourriez avoir plusieurs threads de travail faisant ceci si vous voudriez un parallélisme.

Vous pouvez également avoir une liste des tâches en cours de réalisation et une autre liste indiquant celles qui sont terminées.

Je ne suis pas un programmeur C# mais en Java je chercherais à utiliser une implémentation de l'interface BlockingQueue.