pthread_join plusieurs threads en attente

De opengroup.org sur pthread_join:

Les résultats de plusieurs appels simultanés à pthread_join() en spécifiant le même thread cible ne sont pas définis.

Donc, vous devriez vraiment pas avoir plusieurs threads de rejoindre votre précédente insertThread.

D'abord, comme vous l'utilisation de C++, je recommande coup de pouce.fil. Ils ressemblent à la POSIX modèle de threads, et aussi de travailler sur Windows. Et il vous aide avec le C++, c'est à dire en faisant fonction-objets utilisable plus facilement.

Deuxième, pourquoi voulez-vous démarrer un nouveau thread pour l'insertion d'un élément, lorsque vous de toujours avoir à attendre que la précédente se termine avant de commencer le prochain? Ne semble pas être classique, l'utilisation de plusieurs threads.

Bien que... Un classique de la solution à cela serait d'avoir un seul travailleur-fil de trouver un emploi à partir d'un événement-la file d'attente, et d'autres threads affichage de l'opération sur les événements de la file d'attente.

Si vraiment vous voulez juste pour le garder plus ou moins la façon dont vous l'avez maintenant, vous avez à faire cela:

• Créer une variable de condition, comme insert_finished.
• Tous les threads qui veulent faire un insert, attendre sur la variable de condition.
• Dès qu'un thread se fait avec son insertion, il déclenche la variable de condition.
• Que la variable de condition nécessite un mutex, vous pouvez simplement informer tous les threads en attente, ils ont tous envie de commencer l'insertion, mais comme un seul thread peut acquérir le mutex à un moment, tous les threads ne l'insérer de manière séquentielle.

Mais vous devez prendre soin de votre synchronisation n'est pas mis en œuvre dans un trop ad-hoc façon. Comme c'est appelé insert, je soupçonne que vous souhaitez manipuler une structure de données, alors vous voudrez probablement mettre en œuvre un "thread-safe" de la structure des données tout d'abord, au lieu de partager la synchronisation entre la structure des données-permet d'accéder à tous les clients. Je pense aussi qu'il n'y aura plus d'opérations puis juste insert, qui aura besoin d'une synchronisation correcte...

Oui comme la plupart des gens recommandé le meilleur moyen semble avoir un thread de lecture à partir d'une file d'attente. Quelques extraits de code ci-dessous

    pthread_t       insertThread = NULL;
pthread_mutex_t insertConditionNewMutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t insertConditionDoneMutex    = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t  insertConditionNew      = PTHREAD_COND_INITIALIZER;
pthread_cond_t  insertConditionDone     = PTHREAD_COND_INITIALIZER;
//Thread for new incoming connection
void * newBatchInsert()
{
for(each Word)
{
//Push It into the queue
pthread_mutex_lock(&lexicon[newPendingWord->length - 1]->insertQueueMutex);
lexicon[newPendingWord->length - 1]->insertQueue.push(newPendingWord);
pthread_mutex_unlock(&lexicon[newPendingWord->length - 1]->insertQueueMutex);
}
//Send signal to worker Thread
pthread_mutex_lock(&insertConditionNewMutex);
pthread_cond_signal(&insertConditionNew);
pthread_mutex_unlock(&insertConditionNewMutex);
//Wait Until it's finished
pthread_cond_wait(&insertConditionDone, &insertConditionDoneMutex);
}
//Worker thread
void * insertWorker(void *)
{
while(1)        
{
pthread_cond_wait(&insertConditionNew, &insertConditionNewMutex);
for (int ii = 0; ii < maxWordLength; ++ii)
{                   
while (!lexicon[ii]->insertQueue.empty())
{
queueNode * newPendingWord = lexicon[ii]->insertQueue.front();
lexicon[ii]->insert(newPendingWord->word);
pthread_mutex_lock(&lexicon[ii]->insertQueueMutex);
lexicon[ii]->insertQueue.pop();
pthread_mutex_unlock(&lexicon[ii]->insertQueueMutex);
}
}
//Send signal that it's done
pthread_mutex_lock(&insertConditionDoneMutex);
pthread_cond_broadcast(&insertConditionDone);
pthread_mutex_unlock(&insertConditionDoneMutex);
}
}
int main(int argc, char * const argv[]) 
{
pthread_create(&insertThread, NULL, &insertWorker, NULL);
lexiconServer = new server(serverPort, (void *) newBatchInsert);
return 0;
}

Comme vous venez de le maintenant mentionné que vous êtes en utilisant une table de hachage avec plusieurs look-ups parallèle aux insertions, je vous recommande de vérifier si vous pouvez utiliser en même temps une table de hachage.

Que le regard exact-les résultats sont non-déterministe lorsque vous êtes à l'insertion d'éléments simultanément, par exemple un concurrent de hachage de la carte peut être exactement ce dont vous avez besoin. Je n'ai pas utilisé simultanées hash-tables en C++, si, mais comme ils sont disponibles en Java, vous allez à coup sûr trouver une bibliothèque à faire cela en C++.

Il me semble que vous voulez serialise d'insertions dans la table de hachage.

Pour cela, vous voulez un lock - pas de frai de nouveaux threads.

Idéalement,vous ne voulez plusieurs threadpools dans un seul et même processus, même si elles effectuer différentes opérations. Le resuability d'un thread est un important définition architecturale, ce qui conduit à pthread_join en cours de création dans un thread principal si vous utilisez C.

Bien sûr, pour un C++ threadpool aka ThreadFactory , l'idée est de garder le fil des primitives abstraites ainsi, il peut traiter tout de la fonction/types d'opération passée.

Un bon exemple serait un serveur web qui ont des pools de connexions et des pools de threads qui les connexions de service, puis de les traiter, mais, tous sont issus d'un même pool de threads du processus.

RÉSUMÉ : ÉVITER PTHREAD_JOIN DANS un endroit autre qu'un thread principal.