2010-10-12 9 views
10

Puisque C# supporte le filetage, est-il possible d'implémenter le concept de fourche en C#?Concept de fourche en C#

Merci à l'avance ....

+0

Comme dans la commande unix? Dans ce cas, non. –

Répondre

18

Ceci est plus une question de .NET/CLR que de C#. Généralement, c'est une question de système d'exploitation sous-jacent. Windows ne prend pas en charge la sémantique fork() de la génération de nouveaux processus. En outre, fork() n'a rien à voir avec le support multithread.

La sémantique de fork() implique la duplication du contenu de l'espace adresse du processus d'origine. Mon opinion est qu'il s'agit d'une approche obsolète de la création de processus et qu'elle n'a pratiquement plus de place dans le monde Windows, car elle implique beaucoup de problèmes de sécurité et d'architecture du système d'exploitation. Du point de vue .NET, le problème fondamental avec fork() serait l'approche de la duplication et/ou du partage de ressources non managées (descripteurs de fichiers, des objets de synchronisation, des poignées de fenêtre (!), Etc.) entre l'ancien et le nouveau processus. Je pense qu'il n'y a aucune raison sérieuse d'introduire un tel concept soit à .NET ou au système d'exploitation sous-jacent de Windows.

Pour plus de détails, voir le lien de saurabh.

+0

Une raison sérieuse que je peux penser est de manipuler des deadlocks (forking de fil). C'est une idée avancée. Mais le fait de pousser et de faire sauter les états des fils (fourchette et sommeil du nouveau fil) ainsi que le versionnage des objets verrouillés pourrait vous permettre de revenir en arrière avant que des blocages ne se produisent. (Remarque: les interblocages empêchent la corruption des données ... vous pouvez les laisser partir tous les deux, mais les données ne seront plus verrouillées de manière exclusive - même si un seul thread s'exécute à la fois). Cela nous donne des objets atomiques non bloquants (même blocage des bases de données). C'est une raison sérieuse. – TamusJRoyce

+0

Veuillez noter que 'fork 'ne fournira pas réellement les effets désirés sur .NET. 'fork 'ne fonctionne pas bien avec les applications multithread, cela entraîne la fin de tous les autres threads. Une application .NET est par définition multithread, car au moins un thread GC est en cours d'exécution. – Sebazzz