Lorsque l’on parle de Thread avec le framework .net, le reflexe naturel est de penser au namespace System.Threading. Ce namespace contient en effet presque tout ce que .net vous propose afin de gérer le multithreading.

Cela est peu connu et peu utilisé, mais il est possible de dépasser certaines limites de la classe Thread en utilisant une classe auxiliaire ProcessThread présente quand à elle dans System.Diagnostics. Cette classe fournit tout un tas de service interessant comme la possibilité de définir l’affinité d’un thread afin de le faire exécuter sur un processeur en particulier ce qui n’est pas possible à l’aide de la traditionnelle classe Thread :

using System.Diagnostics;

namespace FurtherWithThreads
{
    class Program
    {
        static void Main(string[] args)
        {
            int threadId = AppDomain.GetCurrentThreadId();
            SetProcessorAffinity(threadId,1);
            while(true)
            {
                
            }
        }

        static void SetProcessorAffinity(int threadId, int processor)
        {
            var processorThread = (from ProcessThread t in Process.GetCurrentProcess().Threads
                                  where t.Id == threadId
                                  select t).Single();
            processorThread.ProcessorAffinity = (IntPtr) processor;
        }
    }
}

Comme vous pouvez le constater le code s’exécute bien sur des cœurs différents comme souhaité.

Les regions sont incontestablement la fonctionnalité que je déteste et qui m’insupporte le plus dans Visual Studio. En voir dans du code, me fait enrager, grogner, avoir des boutons dans 98% des cas où je les rencontre.

Les regions permettent de définir différentes zones dans du code, zones qui peuvent être nommées et qui peuvent être rétractables. Le principal reproche que je trouve aux régions réside tout simplement dans le rôle même de cette fonction : MASQUER LE CODE.

Car après tout, les régions ont été créés dans un seul et unique but : masquer du code que le développeur ne doit pas voir ou modifier :

Cela avait donc une utilité avant que les classes partielles existent afin de masquer du code qui est généré et qui donc par définition ne doit pas être modifié (sous peine de voir les modifications supprimées lors de la prochaine génération de code) en le plaçant dans un autre fichier.

Vous l’avez compris, je ne comprends pas quel est l’intérêt de masquer du code. Lorsque je consulte des fichiers sources je souhaite avoir la meilleure lisibilité possible afin de comprendre le fonctionnement du code que je suis en train de lire. Le voir masqué m’oblige à utiliser mes dons de contorsionniste des doigts afin de déplier ces fameuses régions qui, pour certains développeurs, servent à “ranger” ou “classer” du code source de “manière plus propre”.  Dans la très majorité des cas, si vous avez besoin de “ranger” votre code source présent dans une classe en plus zone, c’est que votre classe fait beaucoup trop de choses que ce qu’elle devrait faire. Repenser la séparation des responsabilités permet de résoudre le problème. Si vous regroupez plusieurs méthodes et/ou propriétés dans une région particulière, il y a une forte probabilité que cet ensemble devrait se trouver dans une autre classe. Et si vous groupez des lignes de code d’une même méthode en plusieurs régions, cela signifie que votre méthode à trop de responsabilité et qu’il serait bon de la splitter en différentes méthodes distinctes.

Le seul avantage que je vois donc aux régions, et qu’il permet de voir du premier coup d’œil quel est le code qu’il est urgent de factoriser.

Dans le genre truc à la con que j'oublie à chaque fois, pour parcourir la callstack durant l'exécution d'un programme - afin de par exemple connaitre la méthode d'appel - il faut utiliser la classe StackTrace présente dans le namespace System.Diagnostics afin de récupérer les différentes StackFrame représentant les différentes frames de votre pile d'appel. La première (indice 0) étant la méthode actuelle et la seconde représentant la méthode d'appel précédente. Vous pouvez ainsi remonter jusqu'où bon vous semble.

Exemple rapide de code :

             static void Main(string[] args)
             {
                    Toto();
             }

             static void Toto()
             {
                    StackTrace trace = new StackTrace();
                    StackFrame frame = trace.GetFrame(1);

                    MethodBase method = frame.GetMethod();

                    Console.WriteLine(frame.GetMethod().Name);
             }

Bart de Smet MVP C# et Microsoftee depuis peu vient de rendre disponible LINQ To AD (Active Directory) sur le site CodePlex. Ce provider est fourni avec son code source, ce qui constitue un excellent point de départ si vous souhaitez apprendre comment créer un provider LINQ.

En savoir plus :
L'annonce sur le blog de Bart de Smet
Linq to AD sur CodePlex