• [^] # Re: Deadlock

    Posté par . En réponse au message Linux pour Amstrad CPC-6128+. Évalué à -1.

    Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction).

    Et si justement, c'est ce que tu n'arrives pas à comprendre. Tu ne peux pas dérouler le nombre d'instructions que tu veux jusqu'à avoir bloqué les interruptions du système et ensuite dérouler ta tâche sans aller droit dans le mur.
    Et je ne confond rien, c'est toi qui ne comprend pas le mécanisme necessaire à la pose d'un lock. Cette opération doit absolument se faire de façon non interruptible par une autre tâche du système donc de façon atomique. Non interruptible ET extremement bref pour ne pas perturber le fonctionnement du système dans son ensemble. Le test ET le set. Sous peine de voir 2 tâches poser un lock simultanément et ensuite continuer leur fonctionnement en tenant pour acquis qu'elles sont propriétaires du lock pendant le temps que se déroulent les opérations suivant la pose du lock jusqu'à sa desactivation.
    Il faut que le noyau ou des tâches plus prioritaires puissent interrompre une tâche ayant posé un lock sous peine de graves problèmes de non prise en compte d'évenements, voire de gel du système tout entier si la tâche ayant posé un lock boucle.
    De plus c'est incohérent de bloquer toutes les interruptions juste pour avoir un pseudo-lock. De mémoire seulement windows 3.11 faisait une énormité comme ça.
    C'est des concepts de base des systèmes temps-réel qui te paraîtraient évidents si les avais un peu pratiqué.
    Pour en revenir au sujet du post. Il faut que ce mécanisme soit possible pour faire fonctionner linux. On ne peut pas faire fonctionner de système multi-tâche ,même non temps-réel, sans un moyen valide de poser des locks.