Supposons que j'ai besoin d'exécuter quelques tâches simultanées.
Je peux envelopper chaque tâche dans un Je me demande quand je dois utiliser l'ancien (avec futur et attendre leur achèvement. Sinon, je peux créer un acteur pour chaque tâche. Chaque acteur exécuterait sa tâche (par exemple lors de la réception d'un message "Démarrer") et d'envoyer le résultat.
futur s) et ce dernier (avec acteur s) Approche et Pourquoi l'approche future est considérée comme meilleure pour le cas décrit ci-dessus.
3 Réponses :
Parce qu'il est syntaxiquement plus simple.
val tasks: Seq[() => T] = ???
val futures = tasks map {
t => future { t() }
}
val results: Future[Seq[T]] = Future.sequence(futures)
La différence est également dans la mise en œuvre sous-jacente, mais le modèle Acteur est en général un modèle de programmation plus puissant et plus expressif - vous pouvez probablement créer une API similaire à l'API à terme utilisant des acteurs. La mise en œuvre des acteurs utilisant des contrats à terme seraient plus lourds.
Ok, je vois la différence entre les modèles. Pourriez-vous expliquer aussi la différence B / W des implémentations?
L'API à terme fonctionne généralement en créant une tâche à fourche / jointure et en le poussant au pool Fork / Rejoindre, qui attribue ensuite la tâche à l'un des threads de travail. Il optimise parfois ceci (la dernière fois que j'ai vérifié) en exécutant les tâches prévues pour l'exécution d'un seul avenir en vrac. La mise en œuvre des acteurs s'appuie également sur une piscine de thread et des messages de manutention stockés dans une boîte aux lettres d'acteur d'une tâche, mais je ne suis pas suffisamment compétente dans ses internes pour vous en dire plus.
Merci beaucoup. Il est intéressant de noter que les tâches correspondent au modèle Modèle modèle (ou futur modèle) mieux. J'y penserai.
En règle générale, utilisez le modèle de concurrence le plus simple qui correspond à votre application plutôt que le plus puissant. Commander à partir de la plus simple à la plupart des complexes serait une programmation séquentielle -> collections parallèles-> contrats à terme-> acteurs apatrides-> acteurs étatiques-> threads avec logiciel de mémoire transactionnelle-> threads avec des algorithmes sans verrouillage. Choisissez le premier dans cette liste qui résout votre problème. Plus vous allez dans cette liste, plus la complexité et les risques sont importants, vous préférez que vous amélioriez la simplicité de négociation pour la puissance conceptuelle.
Où avez-vous pris cette séquence? Pour moi, il semble incompatible, car l'utilisation de futures implique des threads avec un verrouillage explicite. Et, où sont les threads avec verrouillage implicite (à l'aide de la file d'attente de blocage). En outre, ce que l'ensemble des intrants de votre acteur peut-il avoir? Si seulement un (acteurs SCALA et AKKA), vous devez supprimer des acteurs multi-entrées séparément. Si les acteurs que vous voulez dire peuvent avoir plusieurs entrées, il n'y a pas de différence entre les acteurs apatrides et stipuleux (l'état est un jeton transmis à une entrée supplémentaire).
La liste n'était qu'une opinion personnelle. Vos changements sont raisonnables, sauf que les futurs n'impliquent en aucun cas les threads et le verrouillage explicite. Les futurs à effet latéral ont effectivement modéliser les variables de Dataflow et acquérir une concurrence sans permettre le non-déterminisme.
Futures en Java (java.util.concurrent.future) et dans la plupart des autres langues (voir EN.Wikipedia. org / wiki / futures_and_promises ) bloque, et il implique ainsi des threads. De quel avenir parlez-vous?
La mise en œuvre de contrats à terme implique effectivement des threads sous les couvertures, comme à peu près toute construction de la concurrence. Cela dit, je vais affirmer que c'est un modèle plus simple qui threads en général, simplement parce qu'il est (en l'absence d'effets secondaires), déterministe et capable de soutenir le raisonnement local. Les collections parallèles et les acteurs apatrides ont des caractéristiques similaires. Notez que ces modèles sont en réalité plus faible que les threads avec les serrures. Il y a des programmes simultanés que vous ne pouvez pas créer avec des futurs à effet latéral, y compris sans toutefois s'y limiter, les conditions de course.
Je voudrais envisager des contrats à terme comme un cas particulier de files d'attente de blocage et j'appliquer vos considérations à terme à toutes les files d'attente de blocage. Quoi qu'il en soit, j'aime cette discussion, mais je crains que cela soit devenu hors sujet ici. Faites-moi savoir si vous souhaitez continuer dans un autre endroit (e-mail addr est dans mon profil).
J'ai tendance à penser que les acteurs sont utiles lorsque vous avez des threads interagissant. Dans votre cas, il semble que tous les emplois soient indépendants; J'utiliserais futures.
Lire les autres réponses, je pense qu'un nouveau devrait être un peu plus élaboré.