2010-01-19 9 views
2

J'ai une question de conception. Est-il préférable de définir des classes séparées pour SENDING et RECEIVING. Ou est-il préférable de définir une seule classe Thread? J'aime l'idée d'une classe Thread unique car il est plus facile de partager une file d'attente qui peut être verrouillée par mutex.Classe de filetages

design Option # 1 (séparée):

mySendThread = new SendThread(); // Have thread properties and separate members 

myRcvThread = new RcvThread(); // Have thread properties and separate members 

design Option # 2 (Master):

fil Master -

Execute() 
{ 
    if (threadType == RCV_THREAD) 
    { 
     globalVar = new MasterThread(serialPortHandle); 
    } 
    while (!Terminated) 
    { 
     if (threadType == RCV_THREAD) 
     { 
      if(globalVar) 
      { 
       // do work 
      } 
     } 
     if (threadType == SND_THREAD) 
     { 
      tCountSnd = GetTickCount()/SND_THREAD_DELAY; 
      if (tCountSnd != tCountSnd2) { 
       tCountSnd2 = tCountSnd; 
       if (globalVar) { 
        // do sending work 
       } 
      } 
     } 
    } 
} 
+0

Quel est le problème avec les classes de thread existantes telles que celle de Boost? – jalf

+0

Rien. Je ne suis pas en train de concevoir une classe de threads .. Je conçois la mise en œuvre –

Répondre

3

J'ai conçu un fil pour communiquer sur le port série (en Python, pas en C++, mais peu importe) comme suit:

Il y a un seul lire et deux files d'attente - un pour envoyé et un pour les messages reçus. Le thread écoute toujours (de manière asynchrone) à la fois sur le port série (pour les données reçues) et sur la file d'attente d'envoi (pour envoyer les données que l'application demande d'envoyer).

  1. Si les données sont arrivées sur le port série, il est placé dans la file de réception pour Si l'application a placé l'utilisation de l'application
  2. données dans la file d'envoi, le fil, il fait descendre le port série

Cette conception a plus de sens pour moi parce que la seule ressource (le port série) est détenue par un seul thread, et non partagée par deux. Briser à plusieurs classes sonne comme un surpuissant pour moi, depuis la lecture/écriture des files d'attente et la lecture/écriture du port série est une opération triviale (naturellement le port série est enveloppé dans une classe pratique - par la façon dont je recommande vraiment this class par Ramon De Klein)

Oh, et cela fonctionne très bien.

+0

est la file d'attente de réception d'une file d'attente globale partagée entre l'application et le thread Process/Sending? –

+0

C'est un objet Queue synchronisé - cela dépend vraiment de la librairie de threading/synchronisation que vous utilisez en C++ –

+0

comment empêcher la réception d'être bloquée si elle traite des messages ou cette file est-elle transmise à un thread de travail? –

1

En ce qui concerne la file d'attente à partager, enveloppez-la dans une classe séparée et implémentez la gestion du mutex. Chaque classe de threads contient une référence à l'encapsuleur de file d'attente et n'a pas besoin de traiter les mutex du tout.

4

Je pense qu'il est préférable de découpler complètement le but ou l'exécution d'un thread de l'abstraction réelle du thread que vous allez utiliser. Faites de votre classe de threads juste un wrapper mince pour vous permettre de démarrer, d'arrêter et de rejoindre un thread. Avoir un objet functor (ou pointeur de fonction) dans le constructeur pour l'exécution réelle. Ou mieux encore, utilisez l'une des nombreuses abstractions de threads déjà disponibles au lieu d'écrire votre propre (boost :: thread pour un, mais je parie que le framework que vous utilisez a déjà une classe de threads).

+1

+1 pour Boost.Thread. – avakar

0

2ème choix est clairement une mauvaise. Il est préférable d'avoir 2 classes différentes, peut-être vous pouvez avoir une classe de base qui a une implémentation commune. Ceci est juste une évaluation initiale s'il vous plaît fournir plus d'informations sur votre problème seulement alors une bonne analyse du problème peut être fait