J'ai une application asynchrone, ce qui signifie qu'à tout moment, il peut y avoir n événements. Existe-t-il un algorithme connu pour faire une exclusion mutuelle pour n threads, sans encadrer chaque fil d'identifiant?
3 Réponses :
Je ne pense pas que JavaScript en soi est un verrouillage de l'objet - car JavaScript est essentiellement unifamilial. Vous pourrez peut-être trouver une bibliothèque ou une implémentation qui exécute plusieurs threads de code JavaScript - mais fonctionnent-ils tous dans le même espace variable? Ils devront communiquer de la manière d'une manière ou d'une autre.
mutex en quelque sorte, et dans la mesure de votre supposons ' ++ 'est considéré comme une opération atomique pour le système qui fait votre enfilage, comment de cela?
Je peux faire une variable statique sans problème, ma préoccupation n'était pas si je n'étais pas sûr que ++ était une opération atomique. Savez-vous si c'est le cas pour JS? Si c'est vrai, ce problème est (je crois), solvable. Votre fonction ressemble à cela le fait correctement, réellement.
À ce jour aujourd'hui, Chrome n'est plus célibataire. Essayez cet exemple, il utilisera 100% de votre processeur: jsfiddle.net/mtj27/15
Le code que vous avez fourni peut-il être utilisé tel quel? Je veux dire que c'est totalement correct et peut être utilisé en mode de production?
Je m'attends à ce que le comportement de ++ dépend de quel interprète JavaScript est utilisé. Si je lançais un vaisseau spatial avec ce code, j'a) exécuter beaucoup de tests lourdement filetés sur le navigateur spécifique à utiliser, et b) examiner le code d'interprète lui-même. Si plusieurs instances de l'interprète sont en cours d'exécution dans des threads de système d'exploitation réels distincts, @darkzagnel suggère, alors peut-être qu'il n'y a pas d'espoir d'une solution infaillible, à moins que vous ne puissiez trouver une opération de lecture réelle vraiment atomique.
En fait, ne vous inquiétez pas de mutex et de trucs comme ça. Chrome est multithreau que si vous utilisez le travailleur et le travailleur ne partage pas leurs données avec votre code. Vous devez transmettre des données à l'aide de port et de signal. Leur n'a pas accès au DOM, à la fenêtre, au document ou à toute autre variable.
@darkzangel Chrome lui-même (signification, un onglet donné de chrome) est toujours à un seul fileté, mais lorsque vous créez un travailleur, vous créez explicitement un nouveau fil (en fait, il est plus proche d'un nouveau processus, mais de Whatev XD).
JavaScript est généralement à un seul fileté, vous n'avez donc jamais deux pièces de code modifiant les mêmes données en même temps. Vous pouvez utiliser plusieurs threads dans des navigateurs modernes à l'aide de travailleurs Web, mais ils ne peuvent communiquer que par des messages qui passent, sans partager la mémoire, vous n'avez donc pas besoin de vous inquiéter de l'exclusion mutuelle si vous utilisez des travailleurs Web.
J'utilise réellement des travailleurs Web, mais c'est à côté du point. Mon inquiétude est si la fonction Onmessage est appelée deux fois. Bien que cela puisse être "fileté unique", ne le ferez-t-il pas enfoncé par intermittence, si elles finissent par courir dans la même période?
@Michael Quelle ressource essayez-vous de protéger l'accès à votre exclusion mutuelle?
Disons que j'ai un tableau global et je dois stocker quelque chose dessus et renvoyer l'index de l'article stocké. Normalement, je vérifiais la longueur, poussez-la dans la matrice et renvoyez la longueur de la matrice. Mais si le deuxième fil (qui a été appelé dû à un événement asynchrone) est fileté entre la longueur de la matrice et poussant la nouvelle valeur sur le tableau et fait la même chose elle-même, la première fonction renvoie le mauvais index.
Peut être uniformisé, mais parfois, il y a un problème lorsque certaines actions de l'utilisateur exécutent plusieurs threads que nous aimerions éviter (pour ex. Demandes Ajax). Si nous souhaitons faire un sémaphore, nous pouvons utiliser une variable globale. Quoi qu'il en soit, je suis sûr que cela ne devrait pas être fait de cette façon - je ne sais tout simplement pas une meilleure solution car je ne suis pas impliqué dans JS tellement.
J'espère que cela vous aidera dans certaines situations simples: < / p>
Un exemple de besoin de ceci utiliserait un stockage local, qui n'est pas transactionnel et donc non en sécurité si la même page est ouverte dans plusieurs onglets. La mise en œuvre du comportement mutex avec un travailleur partagé pourrait contourner cette limitation.