linux pthread_suspend

Question

Il semble que linux n'implémente pas pthread_suspend et continue, mais j'en ai vraiment besoin.

J'ai essayé cond_wait, mais c'est trop lent. Le travail en cours de traitement s'exécute généralement en 50 secondes, mais parfois en 500 ms. Le problème avec cond_wait est double. Le verrouillage du mutex prend un temps comparable à celui des exécutions en microsecondes et je n'ai pas besoin de verrouillage. Deuxièmement, j'ai beaucoup de fils de travail et je ne veux pas vraiment faire N variables de condition quand ils ont besoin d'être réveillés.

Je sais exactement quel fil est en attente de quel travail et je peux simplement pthread_continuer ce fil. Un thread sait quand il n'y a plus de travail et peut facilement se pthread_suspendre. Cela n'utiliserait aucun verrouillage, éviterait la ruée et serait plus rapide. Le problème est que .... n'a pas de pthread_suspend ou _continue.

Des idées ?

Answer 1

Faire en sorte que le fil attende un signal spécifique.

Utilice pthread_sigmask y sigwait .

Answer 2

Faites en sorte que les threads se bloquent sur un pipe read. Puis envoyez les données par le tuyau. Les threads se réveilleront suite à l'arrivée des données qu'ils doivent traiter. Si les données sont très volumineuses, il suffit d'envoyer un pointeur par le tuyau.

Si des données spécifiques doivent être envoyées à des fils spécifiques, il faut un tube par fil. Si n'importe quel thread peut traiter n'importe quelle donnée, alors tous les threads peuvent se bloquer sur le même pipe et ils se réveilleront à tour de rôle.

Answer 3

Il me semble qu'une telle solution (c'est-à-dire l'utilisation de "pthread_suspend" et "pthread_continue") est inévitablement racoleuse.

Un laps de temps arbitraire peut s'écouler entre le moment où le fil de travail termine son travail et décide de se suspendre, et le moment où la suspension se produit effectivement. Si, pendant ce laps de temps, le fil principal décide que le fil de travail doit reprendre le travail, le "continue" n'aura aucun effet et le fil de travail se suspendra malgré tout.

(Notez que ceci ne s'applique pas aux méthodes de suspension qui permettent de mettre en file d'attente le "continue", comme la méthode sigwait() y read() méthodes mentionnées dans d'autres réponses).

Answer 4

Vous pouvez essayer une option de pthread_cancel mais faites attention si des verrous doivent être libérés, lisez la page de manuel pour identifier l'état d'annulation.

Answer 5

Pourquoi vous préoccupez-vous de savoir quel fil fait le travail ? On dirait que vous vous êtes mis dans un coin et que vous avez besoin d'une astuce pour vous en sortir. Si vous laissiez le thread en cours d'exécution faire le travail, vous n'auriez pas besoin de cette astuce, et vous auriez également besoin de moins de changements de contexte.