Discussion :

[ram-0000]

Dans un environnement de développement Microsoft, les moyens suivants sont disponibles pour permettre la synchronisation de thread ou de process. Je suis bien conscient que ces moyens ont chacuns leurs spécificités (possibilité inter process, notion de pile, ...) mais il y a des cas où plusieurs moyens sont possibles et je n'ai trouvé aucun comparatifs des performances (tel procédé est 50% plus rapide que tel autre)

Les moyens "classiques" que je connais sont (et il y en a certainement d'autres) :
* Event
* Mutex
* Semaphore
* Mailslot
* IOCP port

En ce qui concerne l'accès concurrent à des données partagées, j'ai aussi identifié les moyens suivants :
* Interlocked functions
* Section critique
* mémoire partagée

Est ce que quelqu'un a déjà fait un comparatif ou connait une URL donnant ce comparatif, je n'ai rien trouvé dans le MSDN.

[nicolas.sitbon]

En ce qui concerne l'accès concurrent à des données partagées, j'ai aussi identifié les moyens suivants :
* Interlocked functions
* Section critique
* mémoire partagée

D'un certain Richter, les interlocked functions sont ce qu'il y a de plus rapide pour les accès concurrents (étant donné qu'on reste en user space).
Pour ce qui est de la synchro des threads, j'aime utilisé les Events mais je n'ai aucune idée de leurs performances.

[Médinoc]

Les sections critiques sont également supposées être plus rapides que les mutex, car elles évitent de faire appel au kernel quand c'est possible (typiquement, quand elles ne sont pas bloquées).

[Vincent Rogier]

Les sections critiques sont également supposées être plus rapides que les mutex, car elles évitent de faire appel au kernel quand c'est possible (typiquement, quand elles ne sont pas bloquées).

+1

[ram-0000]

Le problème c'est que bien souvent, il y a une réponse "a priori" (vos réponse en sont une preuve, "ce machin est plus rapide que ce "truc" parce que l'on reste en user space ou parce qu'il ne passe pas en mode kernel) mais il n'y a pas de mesures de performances relatives.

En effet, si par exemple un IOCP port est 0,3% moins rapide qu'un event, je ne vais pas me prendre la tête, j'oublie les event et je travaille uniquement avec les IOCP ports.

[Vincent Rogier]

Ce genre de bench s'appuyant sur des résultats palpables ne court pas les rue.

Donc, tu as forcément des avis non sans preuves...

Dans ce cas, pourquoi ne fais tu un benchmark et nous postes les résultats ?

[ram-0000]

Dans ce cas, pourquoi ne fais tu un benchmark et nous postes les résultats ?

J'y pensais aussi mais cela demande du temps et de la rigueur donc je cherchais d'abord dans le tout fait.

Faire un bench, cela demande :
* Un environnement fiable et reproductible.
* Une description complète de ce que l'on veut tester
* Une description encore plus complète de comment on le teste
* Les méthodes de mesures