Dévoilé durant le MIX11 qui s’est déroulé à Las Vegas en avril dernier, c’est finalement à la date du 16 juin 2011 que Microsoft a décidé de mettre à disposition le kit de développement (SDK) Kinect pour Windows. Les développeurs en herbe ou passionnés peuvent désormais se donner à coeur joie dans la conception d’applications exploitant les fonctionnalités interactives de la machine. Espérons voir fleurir rapidement sur la toile bon nombre d’outils qui sauront tirer partie de ce petit bijou technologique !

Initialement dénommé “Project Natal”, le Kinect possède désormais une place d’honneur dans le World Guiness Book comme étant l'”accessoire High-Tech le plus vendu dans un court laps de temps” (dixit. World Guiness Book). Initialement conçu pour la console de Microsoft, la Xbox 360, le Kinect s’est voulu être une nouvelle façon de jouer aux jeux vidéos sans manettes appelé également Motion Gaming. Il a rapidement réussi à attiser la sympathie du public avec son concept de commande à la fois ludique et innovante et offrant alors de nouvelles possibilités en terme d’intéractions. Disposant de deux caméras, un capteur de champ par infra-rouge et d’un microphone, le Kinect fonctionne par reconnaissance spatiale d’un corps en mouvement.

Mais les curieux n’avaient pas attendu cette sortie pour mettre au point un pilote compatible Windows pour faire leurs premiers essais. C’est ainsi que le kit CL-NUI Platform a sévi sur internet et proposait déjà de prendre le contrôle sur les capteurs vidéos de l’appareil. On a pu voir apparaître quelques démos techniques (des exemples sur http://kinecthacks.net/) prenant en compte la détection de mouvements qui laisse présager d’autres innovations dans la conception d’interfaces interractives différentes du mythique combo clavier/souris ou plus récemment écran tactile : robotique, réalité augmenté, … Minority Report, ça vous rappelle des souvenirs ?

Prérequis:
Matériel

• Dispositif Kinect pour Xbox 360
• PC avec processeur dual-core, 2.66-GHz ou plus
• Windows 7–carte graphique compatible DirectX® 9.0c
• 2-Go RAM (4-Go RAM recommandé)

Logiciel

• Windows 7 (x86 ou x64)
• Visual Studio 2010 Express (ou autre édition 2010)
• Microsoft .NET Framework 4.0

Et pour bien commencer…

En C#

Avec votre Visual Studio préféré, ajouter la référence “Microsoft.Research.Kinect” depuis la GAC (Global Assembly Cache) et appeler l’assembly dans vos codes projets.

Pour l’API NUI
using Microsoft.Research.Kinect.Nui

Pour l’API Audio
using Microsoft.Research.Kinect.Audio

En C++

• Ne pas compiler vos projets C++ avec w_char comme type de séparateur.
• Pour utiliser l’API NUI, faire un include de MSR_NuiApi.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Pour utiliser l’API Kinect Audio, faire un include de MSRKinectAudio.h.
  Localisation : Program Files\Microsoft Research KinectSDK\inc
• Faire le lien vers MSRKinectNUI.lib.
  Localisation :  Program Files\Microsoft Research KinectSDK\lib
• Enfin, s’assurer que les dlls du SDK de Kinect sont présents dans le bon répertoire lors de l’exécution du projet.
  Localisation: Program Files\Microsoft Research KinectSD

Pour plus de détails, je vous recommande de lire la documentation fournie avec le kit de développement (disponible ici) ainsi que de vous appuyer sur les différentes applications démos présentes dans le répertoire “Mes documents\Microsoft Research KinectSDK Samples”.

Have fun

Télécharger le SDK Kinect for Windows

The post Kinect for Windows SDK: Released! first appeared on In Fine - Le Blog.

Détecter les deadlocks en C# / .NET grâce au pattern IDisposable

Si vous êtes développeur en environnement multithread, alors vous vous êtes déjà posé cette question : Où est ce deadlock ? !

Bien sûr, ce deadlock est non-reproductible, il survient chez l’utilisateur, et l’on peut passer des heures à le chercher. Sans jamais être sur d’avoir trouvé LE deadlock qui pose problème !

Vous trouverez dans ce post un exemple de lock qui a pour objectif de

1. Pouvoir détecter les deadlocks
2. Proposer une syntaxe claire et concise
3. Ajouter un overhead minimum en terme de performance à la syntaxe lock C# classique

Petit rappel : qu’est-ce  qu’un deadlock ?

Un deadlock (interblocage dans sa version française que personne n’utilise) est la situation dans laquelle 2 threads s’attendent mutuellement. Cas concret :

1. Un thread T1 acquiert une ressource R1
2. Un thread T2 acquiert une ressource R2
3. T1 demande la ressource R2
4. T2 demande la ressource R1

Avec un schéma :

Exemple de code provoquant un deadlock

void CreateDeadLock()
{
   Object R1 = new object();
   Object R2 = new object();

   Thread T1 = new Thread(delegate() { Work(R1, R2); });
   Thread T2 = new Thread(delegate() { Work(R2, R1); });

   T1.Start();
   T2.Start();
}

void Work(Object acquire, Object demand)
{
   lock (acquire)//T1 take R1 and T2 take R2
   {
      Thread.Sleep(1000);//To ensure that the ressources are taken
      lock (demand)
      {
      }
    }
}

NB : Bien sûr, les situations réelles sont souvent plus compliquées, impliquant par exemple plus de 2 threads ou des locks implicites (écriture dans un fichier…).

Le lock C#

Quand en C# on écrit la syntaxe suivante :

lock (ressource)
{
}

Il se passe en fait à peu près ça :

Object temp = ressource;
Monitor.Enter(temp);
try
{
}
finally
{
   Monitor.Exit(temp);
}

Monitor.Enter acquière le lock, Monitor.Exit le relâche, Le block try-finally est là pour s’assurer que la ressource sera libérée même en cas d’exception. Quant à la référence “temp”, il garantit que c’est bien l’objet acquis qui sera libéré (l’utilisateur ne peut pas la modifier l’objet vers lequel “temp” pointe).

Prévenir les deadlocks avec un Timeout

Le principe pour prévenir les deadlocks implique l’introduction d’un timeout avec un log ou une levée d’exception dans le cas ou le thread échoue à acquérir la ressource demandée.

Voici un exemple de code résolvant le problème.

if (Monitor.TryEnter(ressource, 10000))
{
   try
   {
      //Work
   }
   finally
   {
      Monitor.Exit();
   }
}
else
{
   // Log, stack trace display...
   throw new TimeoutException("Lock acquiring failed");
}

Dans une application avec de nombreux locks, vous conviendrez que cette syntaxe est plus lourde et moins lisible que le lock classique.

Plus grave, elle laisse la possibilité « d’oublier » la libération de la ressource puisque celle-ci incombe au programmeur à chaque utilisation (sisi, ça peut arriver !).

Une solution plus « User-friendly »

L’objectif est de garder le bénéfice du timeout, tout en bénéficiant d’une syntaxe plus concise et claire.

L’idée ici est d’utiliser un Pattern bien connu des programmeurs C++, mais moins des développeurs C# ou JAVA, le principe RAII (Ressource Acquisition Is Initialization).

Le principe RAII

En C++, il y a un moyen simple de s’assurer qu’une ressource sera toujours libérée à la sortie d’une méthode, c’est de l’encapsuler dans un objet créé sur la pile, et de la libérer dans le destructeur de cet objet. En effet, lorsque la méthode se termine (que ce soit par return ou exception), le destructeur de l’objet est appelé et la ressource toujours libérée.

En C# cependant, on ne peut pas appliquer directement cet idiome. En effet :

-L’appel du destructeur d’une classe n’est pas déterministe (il est réalisé par le Garbage Collector)

-Les structures, équivalent C# des objets créé sur la pile en C++, ne peuvent pas avoir de destructeur.

Implémentation du lock par l’utilisation du pattern IDisposable

Pour contourner cette limitation du langage, on peut utiliser le pattern IDisposable.

Voici une première implémentation :

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private Object _ressource;

public LockCookie(Object ressource)
{
   if (Monitor.TryEnter(ressource, TIMEOUT))
   {
      _ressource = ressource;
   }
   else
   {
      // Log, stack trace display...
      throw new TimeoutException("Lock acquiring failed");
   }
}

public void Dispose()
{
   if (_ressource != null)
   {
      Monitor.Exit(_ressource);
   }
}

}

Et son utilisation :

using (new LockCookie(ressource))
{
   //Work
}

Avec ce pattern, une seule ligne permet d’acquérir la ressource, la libération est systématique à l’accolade fermante (même en cas d’exception) et le traitement en cas d’échec n’est pas dupliqué.

CQFD ? Pas tout à fait. Même si l’on peut se satisfera de cette solution dans la plupart des cas, elle créé un overhead non négligeable : il y a création d’objet à chaque acquisition de la ressource (et qui dit création d’objet dit également plus de travail pour le Garbage Collector !).

Optimisation de la solution

Eliminons tout de suite une première piste : transformer notre classe LockCookie en type struct n’optimise pas la solution. Pourquoi ? Parce qu’à l’accolade fermante du using, la méthode Dispose de l’interface IDisposable est appelée, et appeler une méthode d’interface à partir d’un type struct implique un boxing.

Une autre piste consiste à faire de notre classe LockCookie l’objet même de synchronisation. Voici le code qui en résulte.

public class LockCookie : IDisposable
{
private const int TIMEOUT = 10000;
private bool _ressourceAcquired;

public LockCookie Get()
{
   _ressourceAcquired = Monitor.TryEnter(this, TIMEOUT);
   if (!_ressourceAcquired)
   {
      throw new TimeoutException("Lock acquiring failed");
   }
   return this;
}

public void Dispose()
{
   if (_ressourceAcquired)
   {
      //NB : the 2 next lines must be in is order to prevent _ressourceAcquired
      //to be set to true by Get() then reset by this call to dispose
      _ressourceAcquired = false;
      Monitor.Exit(this);
   }
}

}

Et son utilisation :

//For instance, ressource is a class field : LockCookie _ressource = new LockCookie();
using (_ressource.Get())
{
   //Work
}

L’utilisation est sans doute un peu moins évidente, mais aucun objet n’est créé et la libération de la ressource reste implicite et systématique.

Sur le plan des performances, un lock classique coûte selon mes tests 40 ns (40 milliardièmes de secondes), avec la première solution (avec création d’objet), le coût monte à 50 ns, soit un overhead de 25%, la seconde solution descent à 44 ns, soit un overhead de 10%. Le code des tests de performances sont disponibles en bas de l’article.

Conclusion

Ces 2 solutions apportent une réponse centralisée et efficace aux problèmes liés aux acquisitions de ressources en général et aux deadlocks en particulier. Le coût en terme de performance peut paraître important à certains, mais gardons à l’esprit que le temps d’acquisition d’un lock est souvent négligeable en comparaison du temps ou un thread est effectivement bloqué en l’attente d’une ressource. Je suis par ailleurs curieux de connaître d’éventuelles améliorations ou corrections que vous pourriez apporter.

Code d’analyse de la performance :

void TestPerf()
{
TestPerf(ClassicLock,”ClassicLock”);
TestPerf(LockCookieCreation,”LockCookieCreation”);
TestPerf(LockCookieGet,”LockCookieGet”);
}

public static void ClassicLock(){ lock (_lockObject) { } }
public static void UseLockCookie(){using (new LockCookie(ressource)){ } }
public static void UseLockCookie() { using (ressource.Get()) { } }

public delegate void TestPerfDelegate();
public static void TestPerf(TestPerfDelegate testPerfDelegate, string testName)
{
const long nbIteration = 10000000;//10 millions times
const long nanoSecCoeff = 1000000;//1 ms contains 1 million ns

Stopwatch stopwatch = new Stopwatch();
GC.Collect();//Prevent from garbage collection during loop
stopwatch.Start();
for (int i = 0; i < nbIteration; i++) { testPerfDelegate(); } stopwatch.Stop(); double ellapsedNanoSec = (double)(stopwatch.ElapsedMilliseconds * nanoSecCoeff) / nbIteration; Console.WriteLine(testName.PadRight(50) + ellapsedNanoSec); } } [/sourcecode]

The post Détecter les deadlocks en C# / .NET grâce au pattern IDisposable first appeared on In Fine - Le Blog.