Langue C
  1. Langue C
  3. Comment fonctionne le mode blocage dans les sockets unix / linux?
Intereting Posts
Comment utiliser le kernel libcrc32c (ou les mêmes fonctions) dans les programmes de l’espace utilisateur? prendre les commentaires de l’utilisateur Fuite de mémoire possible Valgrind dans OSX El Capitan La concaténation de ssortingng et int aboutit à une erreur de segmentation en C Détecter des memory leaks dans les programmes C? Sur quel stream le message «stack détruite» est-il imprimé? strlen donne un nombre plus grand que la taille d’un tableau Comment appliquer l’ordre des bits de struct avec le compilateur GCC? Fonction moqueuse (pour tester) en C? problème de lieur clang Suppression des doublons dans le tableau Puis-je compter sur malloc renvoyant la valeur NULL? Comment appeler le code MATLAB à partir de C? strcmp () retourne des valeurs en C Spécifiez un nombre littéral de 8 bits?

Comment fonctionne le mode blocage dans les sockets unix / linux?

Le mode de blocage place-t-il cette tâche particulière dans un état “Process Wait”, car je pense que les sockets non bloquantes nécessitent une implémentation “busy-wait” ou “spin-lock”, explicitement de l’utilisateur. Ou bien les sockets en mode blocage ne sont rien d’autre que des implémentations implicites d’attente par le kernel.

Dans les mécanismes de locking tels que les sémaphores / mutex / moniteurs, un locking est généralement obtenu en plaçant la tâche en état bloqué. Je pense que si de telles choses sont possibles avec le locking, le locking de la prise pourrait également être réalisé de la même manière.

Je ne sais pas avec certitude, je pense que l’interrogation n’est pas un moyen efficace, en particulier pour le kernel, car celui-ci a toujours plein de tâches à accomplir.

THX.

Non, les sockets de blocage sont implémentés dans le kernel. Le processus est dans un état non en cours d’exécution et ne consum pas de temps CPU.

Le kernel est libre d’exécuter d’autres tâches jusqu’à ce qu’une activité extérieure le réveille. Par exemple, une interruption matérielle de la carte réseau l’informant qu’il y a des données à lire. Le kernel le lit et le passe à travers la stack réseau, réveillant éventuellement l’application pour traiter les données.

Les timers fonctionneraient de la même manière, mais avec l’interruption du minuteur.

Le kernel interroge peut- être du matériel sous le capot, mais ce n’est pas nécessairement le cas… c’est une question de conception du matériel.

S’il vous plaît voir ma réponse à cette question: C ++ – comment fonctionnent Sleep () et cin?

Basé sur ce que j’ai appris de net / book / et fourni des réponses. Je vais essayer d’être au point.

Par défaut, tous les sockets bloquent. Cela signifie que lorsque nous émettons un appel de socket qui ne peut pas être terminé immédiatement, notre processus est mis en veille en attendant que la condition soit vérifiée. unp – p435

La mise en veille est mise en œuvre en mettant le processus en état d’attente / bloqué. Le planificateur vérifie si le processus bloqué est activé, c’est-à-dire lorsqu’il lui donne le processeur. La réactivité dans ce cas dépend de la résolution temporelle du planificateur.

Ainsi, les appels bloquants ne constituent pas une implémentation implicite de “occupation active” ou de “locking de rotation” à partir du kernel.

Oui, le mécanisme de locking sous-jacent est identique pour la plupart des implémentations. Mettre le processus en état bloqué / en attente.

Bien entendu, l’interrogation n’est pas efficace, c’est-à-dire pourquoi le blocage n’est pas mis en œuvre à l’aide de l’interrogation.