Qu'est-ce que la famine?
Dans les systèmes multitâches, certaines conditions anormales empêchent la progression de l'exécution des processus ou des threads. Je ferai référence aux processus et aux threads simplement comme des "processus". Deux de ces conditions sont appelées dead-lock et live-lock.
Le premier fait référence aux processus qui se bloquent mutuellement, empêchant ainsi l'exécution de l'un ou de l'autre. Ce dernier fait référence à des processus qui s'empêchent de progresser, mais ne bloquent pas réellement l'exécution. Par exemple, ils peuvent continuellement se faire mutuellement annuler les transactions, sans jamais pouvoir les terminer.
Une autre condition est connue comme la famine des ressources, dans laquelle une ou plusieurs ressources finies, nécessaires à la progression des processus, ont été épuisées par elles et ne peuvent être restaurées que si les processus progressent. C'est également un cas particulier de live-lock.
J'aimerais savoir s'il existe une autre définition, notamment académique, de la "famine" qui ne se limite pas à la "famine liée aux ressources". Les références sont particulièrement les bienvenues.
Et, non, ce ne sont pas des devoirs. :-)
Je ne dirais pas que la privation de ressources est un cas particulier de livelock. Habituellement:
Dans un livelock, aucun thread ne progresse mais ils continuent de s'exécuter. (Dans une impasse, ils ne continuent même pas à exécuter)
En cas de famine, certains threads progressent et certains threads ne s'exécutent pas.
Une bonne explication: http://docs.Oracle.com/javase/tutorial/essential/concurrency/starvelive.html . Mais je comprends que le choix de la terminologie peut varier.
En ce qui concerne la famine, la définition que j'ai entendue est:
Supposons qu'il soit possible de spécifier un chemin d'exécution infini (entrelacé) cohérent avec les hypothèses (sémantique des sémaphores, comportement du planificateur du système d'exploitation ...) de telle sorte que le thread T est suspendu en attente d'une ressource et ne soit jamais repris, même s'il était possible infiniment de fois . Alors T est appelé affamé.
Mais la pratique ne correspond pas à cela. Supposons que deux threads exécutent la même section critique dans une boucle infinie. Votre code de synchronisation permet au premier thread d'entrer dans la section critique une fois par heure. Est-ce la famine? Les deux fils sont autorisés à progresser, mais le premier fait son travail douloureusement lentement.
Les plus simples sources de famine sont les sémaphores faibles. Si vous utilisez une primitive de synchronisation (ou créez la vôtre) qui se comporte de la même manière, la famine en résultera.
Problèmes classiques où la famine est bien connue:
Problème de lecteurs-écrivains. Il est possible de synchroniser les threads de telle sorte que (1) les lecteurs pourront affamer les écrivains (2) les écrivains pourront affamer les lecteurs (3) aucune famine ne se produira (Voir http: // en.wikipedia.org/wiki/Readers-writers_problem )
Dîner des philosophes ( http://en.wikipedia.org/wiki/Dining_philosophers_problem )
Pour plus de détails, je recommande de tout cœur Le petit livre des sémaphores (gratuit): http://www.greenteapress.com/semaphores/ .
Vous demandez si chaque famine est causée par l'attente d'une ressource. Je dirais - oui.
Un fil peut être suspendu:
(1) sur certains appels système bloquants - attente/acquisition d'une variable conditionnelle mutex, sémaphore; write (), poll () etc.
(2) sur certaines opérations non bloquantes - comme effectuer des calculs.
La famine sur (1) est la famine sur les ressources (mutex, buffer, etc.).
Starving on (2) est affamé sur CPU - vous pouvez le considérer comme une ressource. Si cela se produit, le problème vient du planificateur.
HTH
Imaginez que vous êtes dans une file d'attente pour acheter de la nourriture dans un restaurant, pour lequel les femmes enceintes ont la priorité. Et il y a tout un tas de femmes enceintes qui arrivent tout le temps.
Vous allez bientôt mourir de faim. ;)
Imaginez maintenant que vous êtes un processus de faible priorité et que les femmes enceintes sont des priorités plus élevées. =)
Un autre domaine où la famine ou le "blocage indéfini" survient généralement est celui des algorithmes de programmation prioritaire. Un algorithme d'ordonnancement prioritaire a la possibilité de laisser indéfiniment certains processus de faible priorité. Un flux constant de processus de priorité élevée peut empêcher l'exécution d'un processus de faible priorité.
En cas d'ordonnanceurs prioritaires, la solution est "vieillissante". Le vieillissement est la technique qui consiste à augmenter progressivement la priorité des processus qui attendent longtemps dans le système.
La famine, c'est simplement quand un processus ou un service n'est pas servi, même lorsqu'il n'y a pas de blocage sur le système.
Ceci est un exemple que je viens de inventer à des fins de clarification.
Imaginez un algorithme qui contrôle l'accès des ordinateurs à un WAN ou quelque chose comme ça. Cet algorithme pourrait avoir une politique qui dit "Fournir un accès prioritaire aux ordinateurs qui utiliseront moins de bande passante.", Cela semblera comme une bonne politique, mais qu'arrive-t-il quand un seul ordinateur veut accéder au réseau pour un téléchargement ftp qui enverra plusieurs Go quelque part. Avec cette seule politique, cet ordinateur va mourir de faim car l'algorithme ne sélectionnera jamais cet ordinateur, car il être toujours d'autres ordinateurs demandant une plus petite utilisation de la bande passante.
C'est ce qu'on appelle la famine.
Work est aussi une sorte de ressource. Lorsque la distribution du travail dans une configuration producteur-consommateur n'est pas équitable (ou idéale), certains threads peuvent ne pas obtenir suffisamment d'éléments de travail pour les occuper tout le temps.
Un processus n'obtient pas une ressource ou des ressources plus longtemps. Ce n'est pas un blocage, car un ou plusieurs processus s'exécutent sans problème. Le vieillissement peut être utilisé pour résoudre ce problème, un facteur de vieillissement est utilisé pour chaque demande.