2012-08-31 5 views
2

Dans notre application, il y a une utilisation intensive de win32 HANDLE, en utilisant CreateEvent, SetEvent/ResetEvent, afin d'effectuer des mécanismes de synchronisation.win32 Handles et multithread

Un de mes collègues m'a demandé si l'accès aux HANDLE pour les événements était thread-safe.

Je ne pouvais pas répondre, car les poignées sont pas thread-safe pour tout objet GDI ...

Mais puisque les événements sont dirigés vers la synchronisation multithread, je ne pouvais pas imaginer qu'ils ne coûtent pas thread-safe.

Pouvez-vous confirmer cela?

+0

Pour ce que ça vaut, les poignées GDI et USER32 sont une bête complètement différente de celle des KERNEL HANDLE: elles ont un handle dans le nom et sont des valeurs opaques, mais elles sont complètement différentes dans les coulisses. En outre, ce n'est pas tellement que les handles GDI ne sont pas thread-safe, tant que certains d'entre eux peuvent avoir thread * affinity *, ou nécessitent une utilisation à partir d'un certain thread. C'est un concept différent de thread * safety *, cependant. – BrendanMcK

+1

Un handle d'événement non thread-safe serait plutôt inutile. Comment allez-vous utiliser l'événement pour signaler un autre thread si ce n'est pas sûr de le faire? – Damon

Répondre

2

Toutes les poignées que vous obtenez à partir des fonctions dans Kernel32 sont thread-safe, à moins que l'article MSDN Library de la fonction ne le mentionne explicitement. Il y a un moyen facile de dire à partir de votre code, un tel handle est fermé avec CloseHandle(). Avec avec le handle n'est pas nécessairement thread-safe, Windows n'aidera pas lorsque vous appelez SetEvent() deux fois mais WaitForSingleObject() qu'une seule fois. Ce qui pourrait être une course de threads dans votre programme, selon la façon dont vous utilisez l'événement.

1

Dépend du type de poignée. Un handle de synchronisation (comme celui créé par CreateEvent) est par définition thread-safe. Un handle de fichier, lorsqu'il est écrit à plusieurs threads simultanément, pas tellement.