La portabilité des pthreads-win32 sur différents compilateurs fenêtres

Question

J'utilise pthreads-win32 pour permettre le filetage support pour les fenêtres.

J'ai un projet multi-plateforme qui utilise pthreads et je veux le faire fonctionner sur Windows avec différents compilateurs et différentes versions OS.

Au moins, selon la documentation pthreads-win32 devrait fonctionner avec MSVC et même MSVC builds fourni.

Mais je ne sais pas si la bibliothèque est testé avec les derniers compilateurs MSVC comme MSVC-2008 et si elle est prise en charge sous Windows 64 bits.

De Votre propre expérience êtes-vous au courant de problèmes avec cette bibliothèque?

• Tout problème avec MSVC8, MSVC9, MSVC10?
• Tout problème avec Windows x86_64?
• Tout problème avec Windows Vista / Windows 7?

Notes:

• Ne pas essayer même de recommander d'utiliser Boost.Thread, je ne suis pas intéressé. Je suis familier avec la bibliothèque Boost.Thread
• Je ne suis pas intéressé à réinventer la roue avec l'API Win32 (qui manque RW-Locks, variables conditionnelles, etc).
• Je ne réussi à compiler un projet avec MSVC-2008 et MinGW GCC-4.3 et exécuter des tests unitaires sur facilement, en utilisant DLL compilé pré-courant de pthreads.

J'ai juste besoin de connaître les limites de pthreads-win32.

Answer 1

Eh bien, paxdiablo a apparemment bien résumé ici. Mais de mon expérience passée avec cette bibliothèque, je peux ajouter une ou deux choses.

Tout d'abord, j'avais utilisé une sous-ensemble des fonctions de la bibliothèque MSVC 2008 sans aucun problème.

En second lieu, certains de mes collègues ont eu ça va sur le x86_64 (avec MSVC2008 et MinGW). Ils ont pas fait face à aucun problème, soit après plusieurs cycles de un bêta et tests QA. Bien que je ne l'ai pas testé moi-même ne peut donc pas être très sûr sur celui-ci.

par les regards des choses, il pourrait être apte à l'emploi. La seule mise en garde est que si vous trouvez un problème, vous serez à la merci d'un pas si la liste de diffusion active (ou peut-être vous pouvez vous salir les mains avec le code source ou quelque chose comme ça).

Answer 2

ne peut pas dire pour certains et cela ne peut pas être ce que vous voulez entendre, mais, étant donné que la dernière version est datée 2006 , je serais très prudent d'utiliser ce dans les derniers compilateurs. Il peut travail, mais il va probablement être à vous pour obtenir ça va. Il semble y avoir beaucoup de discussions au sujet de le faire marcher dans Cygwin et MinGW peu précieux pour MSVC, et rien je trouve au-delà MSVC2005.

En outre, si vous examinez les archives CVS, il y a des fichiers quelques précieux qui ont été mis à jour l'année dernière (la plupart sont il y a deux à cinq ans). Le couple qui date il y a moins d'un an ont la description « Commentaires et modifications de style de code » qui me porte à croire qu'aucun des viandes du produit a été en cours de développement pendant un certain temps.

Maintenant, peut-être que je me trompe, ce qui est juste un incroyablement bien écrit, produit stable, mais ma nature intérieure est plus susceptible de conclure qu'il est l'un des bazillions de bonnes idées qui ont pris le bord.

Et, ayant un regard sur les listes de diffusion, il n'y a que sept messages postés dans les cinq premiers mois de 2010 (dont la plus ancienne a été sans réponse pendant quatre mois) et seulement 59 pour l'ensemble de 2009. me couleur sceptique mais cela ne semble pas comme une communauté de soutien massivement dynamique.

Il semble y avoir un patch pour Windows 64 bits (voir dans le archives 2010) mais, encore une fois, cela semble avoir des problèmes qui sont sans réponse depuis Février et il mentionne que le support pour MinGW:

  

... ce patch (un peu rugueux et ont besoin d'un certain nettoyage final et une extension du test de course makefile pour permettre CROSS ici) permet pthread être construit pour la cible x86_64-pc-mingw32.

est pas le genre de chose que j'utiliserai pour ma mission de logiciels critiques.

Et je sais que vous avez dit que vous n'êtes pas intéressé à réinventer la roue, mais vous pouvez implémenter des verrous multi-lecteur et variables de condition des primitives plus basiques assez facilement - j'ai même eu un système multi-lecteur qui a résolu le problème de la famine écriture d'une manière qui m'a presque obtenu un brevet (pas que je suis d'accord avec les brevets logiciels, mais mon employeur qu'ils insiste précieux êtes la).

Et si la seule roue que vous venez a la moitié de ses rayons disparus et est courbé horriblement hors de forme, vous aurez juste besoin de reconsidérer: -)

Dans tous les cas, Vista et Server2k8 introduit à la fois variables de condition et lecteur mince / serrures écrivain . stockage thread local a été autour depuis Win2K. Je sais que l'aide ne sera pas si vous avez encore besoin de soutenir XP mais je serais à la recherche à l'avenir.

Et puisque vous semblez avoir la portabilité définie comme « Windows uniquement », et toutes les fonctionnalités que vous voulez sont disponibles dans les versions actuelles, je ne suis pas sûr que je vois un avantage à coller avec pthreads. Si vous voulez la portabilité Posix, oui, mais cela ne semble pas être le cas ici.

Answer 3

Surpris que personne n'a suggéré le fil d'Intel Building Blocks. Ils sont très actifs et soutiennent pratiquement tout, avec la dernière version étant il y a moins de deux semaines, et C ++ 0x fonctionnalités si vous utilisez un compilateur conforme.

http://software.intel.com/en-us/ intel-TBB / # sysreq