[débutant][java] Threads, processus, signaux
Plissken
-
YaSM -
YaSM -
Bonjour à tous!
Je sais que le Java permet de se servir de threads. Mais qu'en est-il des processus? A priori dans l'appli sur laquelle je vais bosser, il n'est pas nécessaire que mes processus aient le même espace mémoire (qu'ils soient donc des threads). S'il n'y a pas de processus, puis-je les remplacer sans problème par des threads?
Leur utilisation est-elle aisée (comparativement par exemple à la gestion des processus sous Linux)?
Existe-il des systèmes de signaux/handlers en java comme sous Linux pour interrompre les threads ou processus?
Merci d'avance pour toute réponse.
Plissken.
Je sais que le Java permet de se servir de threads. Mais qu'en est-il des processus? A priori dans l'appli sur laquelle je vais bosser, il n'est pas nécessaire que mes processus aient le même espace mémoire (qu'ils soient donc des threads). S'il n'y a pas de processus, puis-je les remplacer sans problème par des threads?
Leur utilisation est-elle aisée (comparativement par exemple à la gestion des processus sous Linux)?
Existe-il des systèmes de signaux/handlers en java comme sous Linux pour interrompre les threads ou processus?
Merci d'avance pour toute réponse.
Plissken.
A voir également:
- [débutant][java] Threads, processus, signaux
- Jeux java itel - Télécharger - Jeux vidéo
- Waptrick java football - Télécharger - Jeux vidéo
- Waptrick java voiture - Télécharger - Jeux vidéo
- Java apk - Télécharger - Langages
- Eclipse java - Télécharger - Langages
2 réponses
D'un point de vue théorique (car je ne connais presque pas Java, je suis assez réfractaire et puriste du C++ :P )
Oui, thread et processus sont des concepts très proches et interchangeable, tu peux les utilisés sans soucis pour ton appli.
Tu as bien cerné la différente processus/thread (au niveau de l'utilisation) est un problème de partage de la mémoire.
Un fork() en C va dupliquer toute la mémoire du processus (en crée un clone) alors qu'un pthread (toujours en C) ne crée qu'un nouveau fil d'exécution (deux fonction du même process sont éxécutées simultanéments).
En général, depuis qu'il existe, on préfère les threads au fork (je ne connais pas de contre exemple, à par les puriste qui restent bloqués sur le fork parcequ'ils savent l'utiliser).
Le reste de ta question est technique et liée au Java, donc je ne peux pas y répondre.
Autre chose : vu que les ressources sont partagés entre les threads, ce qui est bien pratique, il faut aussi voir que ça peux créer des embêtement. Exemple simple : Un thread A modifie une chaine de caractère.
Un thread B la lit. Comme tu ne maitrise pas le moment où le processeurr va commuter de A à B, il se peux que se soit en plein milieu de la modification que fait A. Tu te retrouve dans B avec une ressource inconsistante (une chaîne à moitiée modifiée).
Ainsi toutes les ressources partagée doivent être munies d'un "mutex" (MUTual EXclusion) qui se vérouille en début de section critique (accès à la ressource partagée) et se dévérouille ensuite.
Ainsi, B, quand il voudra lire la donnée, tentera de vérouillé le mutex, l'échec l'informera que la ressource est en cours d'utilisation, il rendra alors la main...
Ceci dis, il y a un deuxième piège. Prenons maintenant 2 ressources rA et rB, munie des mutex mA et mB.
le thread A accède aux deux ressources dans l'ordre rA puis rB.
Le thread B c'est l'inverse. Supposons également que le codeur est pas très au courant et imbrique les vérouillages. Pour le thread A ça donne
Pour le thread B, c'est symétrique.
On se retrouve avec un inter-blocage (deadlock) : lorsque le thread A arrive sur le vérouillage de mB, il bloque, puisqu'il a été vérouillé par threadB.
Et inversement, B bloque sur le vérouillage de mA. De plus, ni l'un ni l'autre, ne peuvent dérouiller les mutex !!
Voilà, c'est un peu chiant, mais inhérent aux multi-tâche (les mêmes problème existe, identique, avec des processus).
Oui, thread et processus sont des concepts très proches et interchangeable, tu peux les utilisés sans soucis pour ton appli.
Tu as bien cerné la différente processus/thread (au niveau de l'utilisation) est un problème de partage de la mémoire.
Un fork() en C va dupliquer toute la mémoire du processus (en crée un clone) alors qu'un pthread (toujours en C) ne crée qu'un nouveau fil d'exécution (deux fonction du même process sont éxécutées simultanéments).
En général, depuis qu'il existe, on préfère les threads au fork (je ne connais pas de contre exemple, à par les puriste qui restent bloqués sur le fork parcequ'ils savent l'utiliser).
Le reste de ta question est technique et liée au Java, donc je ne peux pas y répondre.
Autre chose : vu que les ressources sont partagés entre les threads, ce qui est bien pratique, il faut aussi voir que ça peux créer des embêtement. Exemple simple : Un thread A modifie une chaine de caractère.
Un thread B la lit. Comme tu ne maitrise pas le moment où le processeurr va commuter de A à B, il se peux que se soit en plein milieu de la modification que fait A. Tu te retrouve dans B avec une ressource inconsistante (une chaîne à moitiée modifiée).
Ainsi toutes les ressources partagée doivent être munies d'un "mutex" (MUTual EXclusion) qui se vérouille en début de section critique (accès à la ressource partagée) et se dévérouille ensuite.
Ainsi, B, quand il voudra lire la donnée, tentera de vérouillé le mutex, l'échec l'informera que la ressource est en cours d'utilisation, il rendra alors la main...
Ceci dis, il y a un deuxième piège. Prenons maintenant 2 ressources rA et rB, munie des mutex mA et mB.
le thread A accède aux deux ressources dans l'ordre rA puis rB.
Le thread B c'est l'inverse. Supposons également que le codeur est pas très au courant et imbrique les vérouillages. Pour le thread A ça donne
Verouiller( mA ); // accès à) rA Verrouiller( mB ); // accès à rB Déverrouiller( mB ); Déverouiller( mA );
Pour le thread B, c'est symétrique.
On se retrouve avec un inter-blocage (deadlock) : lorsque le thread A arrive sur le vérouillage de mB, il bloque, puisqu'il a été vérouillé par threadB.
Et inversement, B bloque sur le vérouillage de mA. De plus, ni l'un ni l'autre, ne peuvent dérouiller les mutex !!
Voilà, c'est un peu chiant, mais inhérent aux multi-tâche (les mêmes problème existe, identique, avec des processus).
Bonjour,
je voulais juste rajouter quelques choses qui peut etre utiles. En java c'est des objets qui peuvent etre partagés. donc je pense c'est une modelisation des autres langages qui parlent de partage de memoire. Et l'utilisation des threads en java est simple. Si les threads sont independants ca c'est encore simple mais si les threads depondent l'un de l'autre et bien il faut les coordoner en utilisant par exemple les methodes wait() ret notify().
Voilà c'était juste une petite remarque qui peut être utile.
je voulais juste rajouter quelques choses qui peut etre utiles. En java c'est des objets qui peuvent etre partagés. donc je pense c'est une modelisation des autres langages qui parlent de partage de memoire. Et l'utilisation des threads en java est simple. Si les threads sont independants ca c'est encore simple mais si les threads depondent l'un de l'autre et bien il faut les coordoner en utilisant par exemple les methodes wait() ret notify().
Voilà c'était juste une petite remarque qui peut être utile.
Merci Encore!
Quelqu'un pourrait-il m'en dire plus sur le Java?
Plissken.