Quels sont les compromis pour “attente active” vs “sommeil”?

C'est dans le prolongement de ma question précédente

Comment fonctionne le mode de blocage dans unix/linux sockets œuvres?

Ce que je comprends à partir d'Internet, aujourd'hui, tous les processus de l'invocation de blocage des appels, sont mis en sommeil jusqu'à ce que le planificateur trouve les raisons de le débloquer. Les raisons peuvent varier d'un tampon vide de la mémoire tampon pleine de toute autre condition.

Mais alors cela peut-il être un moyen efficace de faire en temps réel, permet de dire dur/ferme les applications en temps réel? En tant que le processus n'est pas débloqué lorsque le déblocage condition vraie, mais plutôt de savoir quand le planificateur de lui donner son CPU tranche, et le déblocage, la condition est à la fois vrai.

Que si tu veux une solution réactive, je n'ai pas ce "spin locks" ou "occupé attend" sont la bonne façon de le faire, CPU tranches sont gaspillées, et sur-tout le système doit obtenir de l'onu sensible ou peut-pauvres-sensibles.

Quelqu'un peut-il svp effacer cette idées contradictoires.

InformationsquelleAutor Vivek Sharma | 2009-07-10

c linux operating-system

39

D'aller dormir jusqu'à ce que le planificateur vous réveille, c'est la normale/a préféré chose à faire.

De filature (l'alternative à attendre, sans dormir) est moins que d'habitude et a les effets suivants:
- Garde le CPU, et empêche les autres threads de l'utilisation de la CPU (jusqu'à ce que le filer termine son timeslice et est prempted)
- Peut arrêter de tourner l'instant, la chose de laquelle vous êtes en attente de ce qui arrive (parce que vous êtes en permanence de vérification pour cet événement, et vous n'avez pas besoin de prendre le temps qu'il faut pour être réveillé, parce que vous êtes déjà éveillé)
- N'invoquent pas le CPU istructions nécessaire d'aller dormir et de se réveiller de nouveau
La filature peut être plus efficace (moins de CPU total) que d'aller dormir, si la durée du retard est très court (par exemple si le retard est uniquement pour la durée nécessaire à l'exécution de 100 instructions du PROCESSEUR).
- +1 pour longueur du délai est très court
InformationsquelleAutor ChrisW
4

Un Verrou de rotation burns CPU et le interrogées chemin d'accès aux ressources pour poursuivre le gaspillage de ressources lors de l'événement souhaité ne pas se produire.

Un Blocage fonctionnement le plus important diffère en laissant le PROCESSEUR et les ressources associées chemin d'accès et l'installation d'un wait d'une certaine forme d'exploitation de la ressource à partir de laquelle l'événement souhaité est prévu.

Dans un multitâche ou multithread/processeur de l'environnement (le cas habituel pour un long moment maintenant), où il y a d'autres opérations possibles pendant l'événement désiré n'est pas arrivé, la gravure du PROCESSEUR et de l'accès aux ressources chemins mène à un terrible gaspillage de puissance de traitement et de temps.

Lorsque nous avons une hyperthreading système (comme je pense que vous faites référence dans votre question), Il est important de noter que le niveau de granularité auquel CPU filets sont des tranches est très élevé. Je m'en tiendrais à mon cou à observons également que tous les événements -- sur lequel vous auriez tendance à bloquer devrait prendre le temps de se poser, la compensation de la petite tranche de temps, qu'ils ont d'attente supplémentaire avant de déblocage.

Je pense que J-16s point est à la condition où un couchage (bloqué) thread est en laissant son code et les données de l'espace inutilisée, tandis que dans l'état bloqué. Cela pourrait faire un système de renoncer à des ressources (comme des données/code caches), qui devraient ensuite être réutilisé lorsque le bloc est libéré. Par conséquent, soumise à conditions, un bloc peut en effet en plus de gaspillage de ressources.

Ceci est aussi valable et devrait être vérifié dans la conception et la mise en œuvre.

Mais, le blocage est généralement mieux que les spin-serrures dans la plupart des conditions.
- bon, je pense que je vais mettre en place une réponse et de voir si des gens sont d'accord, ou je me trompe. Merci bien. Oui j16 a apporter une perspective différente. c'est gentil. et Merci nik pour la mettre en exergue. 🙂
InformationsquelleAutor nik
1

Si dans le cas d'utilisation de votre application, le changement de contexte serait plus cher que de manger quelques cycles CPU parce que votre état serait assuré d'avoir satisfait à l'intérieur d'un court
temps, puis occupé attente peut être bon pour vous.

Sinon, vous pouvez avec force renoncer à la CPU de couchage ou cond_wait()ing.

Un autre scénario que je peux penser de pouvoir la commutation de contexte est comme suit:
```
while(condition)
    sleep(0);
```
InformationsquelleAutor Jay D
0

Tout d'abord, vous avez une idée fausse:

Blocage des appels ne sont pas "occupé attente" ou "spin locks". Blocage des appels sont sleepable-ce qui signifie que le PROCESSEUR serait de travailler sur d'autres tâches, pas de cpu sont gaspillées.

Sur votre question sur le blocage des appels

Blocage des appels sont plus faciles -- ils sont faciles à comprendre, plus faciles à développer, plus facile à déboguer.

Mais ils sont mangeur de ressources. Si vous n'utilisez pas de fil, ce serait de bloquer d'autres clients; Si vous utilisez du fil, chaque thread prendre de la mémoire du système et d'autres ressources. Même si vous avez beaucoup de mémoire, de commutation de fil rendrait le cache de froid et de réduire les performances.

C'est un compromis -- un développement plus rapide et la facilité de maintenance? ou d'évolutivité.
- c'est exactement ce que j'ai dit, "bloquer les appels sont sleepable" s'il vous plaît re-lire de nouveau la question.
- Comment pourrait-appels de blocage être mangeur de ressources, s'ils dorment, ils ne les mange pas de tout PROCESSEUR.
- ici est surtout de la mémoire
- Tout le monde ici parle de CPU-cycles, donc je pense que la ressource (bien que subjectivement) est clairement CPU. Et aussi, selon moi, le fil de commutation est différent du changement de contexte d'un processus. Eh bien, cela dépend de la façon dont les fils sont attachés à LWPs de noyau, mais un autre de mise en œuvre de sujet spécifique. Ah ok u veux dire dans votre réponse, vous faites référence à des ressources comme la mémoire.
- la commutation de threads ne change pas l'ensemble de l'espace mémoire, mais il commutateur de registres et de la pile, c'est une commutation de contexte. Même si vous ignorez l'utilisation de la mémoire (qui peuvent être importantes), et le changement de pile et remplissage des caches n'coût en temps de calcul.
InformationsquelleAutor J-16 SDiZ
0

Je vais essayer d'être au point assez d'explication est donnée ici par le biais d'autres réponses et oui, l'apprentissage de toutes ces réponses, je pense que l'image est complète doit être. ---

Compromis selon moi entre Réactivité Vs Débit du système.

Réactivité - peut être considérée de deux points de vue
- sur toutes la réactivité du système, et
- un particulier ou par processus réactivité
Je pense que pour réactivité du système, le blocage des appels sont la meilleure façon d'aller. Comme elle donne à l'UC pour les autres processus dans la file d'attente prêt, lorsque le blocage d'appel dans l'état bloqué.

Et bien-sûr, pour un processus particulier ou par processus réactivité, nous allons considérer un occupé-attendre/spin-lock modèle.

Maintenant, de nouveau à augmenter l'ensemble des la réactivité du système nous ne pouvons pas diminuer la de la tranche de temps (grain fin) pour le planificateur, ce qui permettrait de perdre trop de ressources PROCESSEUR dans le contexte de l'interrupteur. Et donc débit du système diminuerait considérablement. Bien-sûr, il est évident que le blocage de modèle augmente le débit du système, comme les appels bloqués ne consomme pas de CPU tranches et la donne à l'autre/processus suivant dans la file d'attente prêt.

Je pense que le mieux à faire est d'-- conception d'un système avec une par processus réactivité à l'esprit, sans y apporter de la réactivité globale et le débit est--
par le biais de la mise en œuvre d'une priorité en fonction de planificateur, avec des considérations pour inversion de priorité des questions, si en ajoutant de la complexité ne vous dérange pas :).
- Tiens seulement à ajouter: j'espère que tu sera bien peser le spin-lock de l'utilisation des ressources des inefficacités efficace contre les retards de mode de blocage (généralement fine, matériel) ordonnancement temps-tranches.
- Oui nik, vous avez droit, tout le débat autour de ce compromis.
InformationsquelleAutor Vivek Sharma

-2

//Adaptées ASPI code source d'origine...

    DWORD startStopUnit (HANDLE handle, BOOL bLoEj, BOOL bStart)
    {
       DWORD  dwStatus;
       HANDLE heventSRB;
       SRB_ExecSCSICmd s;





    //here
       heventSRB = CreateEvent (NULL, TRUE, FALSE, NULL);

       memset (&s, 0, sizeof (s));

       s.SRB_Cmd = SC_EXEC_SCSI_CMD;
       s.SRB_HaID = 0;
       s.SRB_Target = 0;
       s.SRB_Lun = 0;
       s.SRB_Flags = SRB_EVENT_NOTIFY;
       s.SRB_SenseLen = SENSE_LEN;
       s.SRB_CDBLen = 6;
       s.SRB_PostProc = (LPVOID) heventSRB;
       s.CDBByte[0] = 0x1B;
       s.CDBByte[4] |= bLoEj ? 0x02 : 0x00;
       s.CDBByte[4] |= bStart ? 0x01 : 0x00;

       ResetEvent (heventSRB);
       dwStatus = SPTISendASPI32Command (handle,(LPSRB) & s);
       if (dwStatus == SS_PENDING)
         {
//and here, don´t know a better way to wait for something to finish without processor cicles
        WaitForSingleObject (heventSRB, DEFWAITLEN);
         }
       CloseHandle (heventSRB);

       if (s.SRB_Status != SS_COMP)
         {
    printf("Erro\n");
        return SS_ERR;
         }

       printf("nao Erro\n");
       return s.SRB_Status;
    }

InformationsquelleAutor Mandrake

Vous devez vous connecter pour publier un commentaire.