Est-il possible de savoir si un processus est en attente à l'état Bloqué lors d'un appel Receive () sous Linux?

Question

Mon objectif principal est d’exécuter les processus un par un en alternance jusqu’à ce que l’un d’eux appelle receive () et soit bloqué, de sorte que l’exécution passe au processus suivant de la file d’attente. Il existe une application de contrôleur codée en Java qui exécute ces processus (qui sont également des applications Java) à l'aide de Runtime.getRuntime (). Exec () et conserve les valeurs de retour qui sont des objets Process.

Pour atteindre cet objectif, je dois capturer les appels receive () (ou leurs états, qui sont bloqués) et les informer de l'application du contrôleur (maître).

Je peux aller aussi bas que vous le souhaitez si cela est possible. Ma première idée a été d'obtenir ces informations du pilote, puis de les transmettre à l'application Java de mon contrôleur. J’ai écrit un module réseau du noyau Linux qui capture les opérations d’envoi et de réception, mais autant que je sache, la fonction socket.receive () ne dit rien au pilote réseau.

Donc, je pense que les options sont d’obtenir ces informations de la machine virtuelle Java, d’une manière ou d’une autre, d’une commande linux ou autre, ou éventuellement du module de noyau Linux?

Quelles sont vos suggestions?

Answer 1

Si vous voulez savoir si vos threads sont bloqués ou sur quoi ils sont bloqués, vous pouvez effectuer un vidage de threads ou utiliser un outil tel que jvisualvm à attacher au processus et à jeter un coup d'oeil (dans jvisualvm, vous attacheriez au processus, effectuez un vidage de threads , puis regardez l'activité de chaque fil).

Answer 2

Avez-vous consulté la capture système ? Devrait être facilement disponible sur les systèmes Fedora récents.

Meilleur Anders

Answer 3

Je ne sais pas si cela vous aidera, mais vous pouvez obtenir des informations sur l'état d'un thread Java sur votre ordinateur à l'aide de l'attachement local.

1) Ajoutez le fichier tools.jar à votre chemin d'accès aux classes et utilisez VirtualMachine.list () pour obtenir la liste des machines virtuelles Java en cours d'exécution sur votre ordinateur.

2) Attachez-vous à la machine virtuelle traitée à l'aide de VirtualMachine.attach (virtualMachineDescriptor)

3) Obtenez l'adresse du connecteur local, vm.getAgentProperties (). get ("com.sun.management.jmxremote.localConnectorAddress");

4) Utilisez JMXConnectorFactory.newJMXConnector (...) pour vous connecter à la machine virtuelle Java

5) À partir de la connexion JMX, recherchez le ThreadMXBean

6) Dans ThreadMXBean, vous obtenez un tableau de ThreadInfos décrivant tous les threads de la machine virtuelle.

7) À partir de TheadInfo # getThreadState (), vous pouvez vérifier si l'état est ThreadState.BLOCKED

Answer 4

Vous devez utiliser des primitives de communication interprocessus dans vos processus de travail pour informer l’application du contrôleur qu’elles sont prêtes à recevoir des données.

Vous ne pouvez pas présumer de la manière dont les processus enfants implémentent leur lecture de socket. Ils peuvent utiliser recv, sélectionner, interroger, etc. pour attendre les données du réseau.

Answer 5

Il y a en réalité quelques points ici. Le planificateur Linux est suffisamment intelligent pour anticiper une tâche bloquée. En d'autres termes, si vous appelez receive () et que rien n'est en attente de réception, votre tâche sera probablement suspendue jusqu'à ce que l'appel soit renvoyé. Vous n'avez pas besoin de gérer la planification; le noyau Linux le fera pour vous.

Cela dit, si vous avez besoin de savoir si votre tâche est bloquée par une application démon, si vous êtes prêt à écrire un LKM, pourquoi ne pas simplement insérer la tâche dans la liste des tâches qui vous intéresse et cochez son état?

Bien sûr, le simple fait de vérifier l’état de la tâche peut ne pas vous dire exactement ce que vous voulez. Si l'état de votre tâche est TASK_INTERRUPTIBLE , il vous indique simplement que votre tâche est en attente de quelque chose , mais le problème n'est peut-être pas anodin de savoir ce que c'est. De même, votre tâche peut être dans un état TASK_RUNNING et ne pas être réellement exécutée sur la CPU au moment actuel (mais au moins, dans l'état TASK_RUNNING , vous connaissez votre tâche. n'est pas bloqué).

Answer 6

Vous pouvez simplement envoyer un signal QUIT (Ctrl- \ sur la console) pour obtenir un dump de thread.