Y a-t-il un problème d'utilisation de la plaque sur le même descripteur de fichier à partir de 2 fils ou plus différents en même temps?
3 Réponses :
Je ne suis pas sûr à 100%, mais je pense que la structure descripteur de fichier elle-même n'est pas la sécurité du fil, de sorte que deux changements simultanés de la corruption. Vous avez besoin d'une sorte de verrouillage.
Il n'y a pas de structure pour corrompre du côté de l'application, le descripteur de fichier n'est qu'un chiffre.
C'est en fait un index dans une table avec une structure de données. Qui change la table? Le temps d'exécution ou le noyau? Si le temps d'exécution C met à jour le décalage du fichier actuel, c'est dangereux. Si c'est le noyau, alors cela pourrait être le fil sûr.
La table descripteur de fichier est dans le noyau et le runtime C n'a pas accès à celui-ci. Bien sûr, le code du noyau doit être le fil-vitré.
Comme nous utilisons la même FD, nous devons lier un verrou, sinon il y aura une combinaison de données à partir du descripteur de fichier sur le descripteur de fichiers. Par conséquent, oui, il y a un problème à faire cela
Cette réponse est fausse. Le but entier de préad est que vous spécifiez la position que vous souhaitez lire à partir et que les modifications de position résultant d'autres threads / processus n'affectent pas votre lecture. Notez que cela ne fonctionne que sur des fichiers ordinaires et peut-être d'autres périphériques de recherche, pas de tuyaux / tys / sockets / etc.
La vraie question est la suivante: que se passe-t-il si vous lisez simultanément du même fichier (pas nécessairement de deux threads, mais aussi de deux processus).
Concernant ceci, le Spécification dit:
Le comportement de plusieurs lectures simultanées sur le même tuyau, FIFO ou terminal est indéterminé.
Notez qu'il ne mentionne pas les fichiers ordinaires. Ce bit ne concerne qu'à E / S est destiné à être atomique aux fichiers et aux pipes ordinaires et aux FIFOS.
Mais cela provient de la section non normative, votre système d'exploitation pourrait donc le faire différemment. E.G., Si vous lisez à partir de deux threads et que vous trouverez une écriture concomitante, vous pourriez obtenir différentes pièces de l'écriture dans vos deux tampons de lecture. Mais ce type de problème n'est pas spécifique à la multithreading.
aussi agréable de savoir que dans certains cas
lire () doit bloquer le fil d'appel
Pas le processus, juste le fil. Et
Un fil bloqué ne doit pas empêcher tout fil non bloqué [...] de faire progresser progressivement
préad est le fil-faire-coffre-fort, car il ne figure pas sur le Liste des fonctions dangereuses . Donc, il est prudent de l'appeler.
Lire de toute façon, car préad ne peut pas être utilisé sur des fichiers non coquins.