relation entre Managed Faire respecter cette discussion et OS fil (CUDA usecase)

Question

Problème

Je suis en train de créer une application CUDA qui est bien intégré avec .net. L'objectif de conception est d'avoir plusieurs fonctions CUDA qui peuvent être appelées à partir du code managé. Les données doivent également pouvoir rester sur un périphérique entre les appels de fonction, de sorte qu'il puisse être transmis à plusieurs fonctions CUDA.

Il est important que chaque pièce de données est accessible uniquement par un seul thread OS (tel que requis par CUDA)

Ma stratégie

J'enroulant des fonctionnalités et des pointeurs de périphériques CUDA Code C++ géré. Un pointeur de périphérique CUDA peut être enveloppé dans une classe DevicePointer écrite en MC++. Si la classe suit le thread qu'elle utilise, elle peut faire en sorte qu'un seul thread puisse accéder au pointeur de périphérique CUDA.

Je vais alors concevoir le programme de sorte qu'un seul thread essaye d'accéder à une donnée donnée.

Là où je besoin d'aide

Je l'ai fait quelques recherches, et lu sur la distinction entre les threads gérés et les fils OS. Il semble qu'il y ait, en général, une relation de plusieurs à plusieurs entre les deux. Cela signifie que même si je n'utilise qu'un seul thread géré, il peut changer les threads du système d'exploitation et perdre l'accès à un pointeur de périphérique.

Existe-t-il un moyen de forcer le CLR à ne pas déplacer un thread géré entre threads OS?

Answer 1

Utilisez les BeginThreadAffinity et EndThreadAffinity méthodes:

try 
{ 
    Thread.BeginThreadAffinity(); // prevents OS thread switch 

    // your code 
    // ... 
} 
finally 
{ 
    Thread.EndThreadAffinity(); 
} 

Answer 2

je doute que vous devez faire quoi que ce soit. IIRC, le «commutateur de thread OS» signifie que le système d'exploitation peut déplacer le thread d'un processeur à un autre (ou même à un autre processeur dans des systèmes multi-socket) quand il pense que cela améliorera les performances. Mais Cuda ne se soucie pas vraiment de savoir quel noyau de processeur/"thread de système d'exploitation" exécute le code. Tant qu'un seul thread géré à la fois peut accéder aux données, il ne devrait y avoir aucune condition de concurrence. Les API d'affinité des threads ne sont généralement utilisées que lorsque quelqu'un s'énerve totalement à propos de la différence de performance dans l'accès aux localisations de mémoire CPU provenant de différents cœurs. Mais puisque vos données persistantes sont (je suppose) dans les tampons de texture GPU et non dans la mémoire CPU, même cela n'est pas pertinent.