我正在使用pthreads-win32来允许对windows进行线程支持。
我有一个使用pthreads的跨平台项目,我想让它在各种编译器和不同操作系统版本的Windows上工作。
至少,根据文档,pthreads-win32应该与MSVC一起使用甚至
提供MSVC构建。
但我不知道该库是否已经过最新的MSVC编译器测试,如MSVC-2008和
如果在64位窗口下支持它。
从 你自己的经历 你知道这个库有什么问题吗?
- MSVC8,MSVC9,MSVC10有什么问题吗?
- Windows x86_64有什么问题吗?
- Windows Vista / Windows 7有任何问题吗?
笔记:
- 甚至不尝试推荐使用Boost.Thread,我对此并不感兴趣。而且我对Boost.Thread库很熟悉
- 我对使用Win32 API(缺少RW-Locks,条件变量等)重新发明Wheel感兴趣。
- 我确实设法使用MSVC-2008和MinGW GCC-4.3编译项目,然后使用当前预编译的pthreads DLL轻松地对其进行单元测试。
我只需要知道pthreads-win32的局限性。
好, paxdiablo 显然在这里总结了一下。但是从我过去使用这个库的经验来看,我可以在这里添加一些东西。
首先,我在MSVC 2008中使用了库的功能子集,没有任何问题。
其次,我的一些同事已经开始使用x86_64(使用MSVC2008和MinGW)。经过多次beta和QA测试后,他们没有遇到任何问题。虽然我自己没有测试过,但对此不太确定。
因此,根据事物的外观,它可能适合使用。这里唯一需要注意的是,如果你发现任何问题,你将受到一个不那么活跃的邮件列表的摆布(或许你可能想要弄清楚源代码或类似的东西)。
不能肯定地说,这可能不是你想听到的,但鉴于最后一个版本已过时 2006年,我会非常警惕在最新的编译器中使用它。它 可能 工作,但它可能会由你决定。似乎有很多关于让它在Cygwin和MinGW中工作的讨论,但对MSVC来说很少见,而且 没有 我可以找到超越MSVC2005。
此外,如果您检查CVS档案,那么去年(大多数是两到五年前)更新的文件很少。这对夫妇的日期不到一年,有“评论和代码风格的变化”,这让我相信产品的所有内容都暂时没有得到积极的发展。
现在也许我错了,这只是一个写得非常好的,稳定的产品,但我内心的本性更有可能得出结论,这是一个被淘汰的好主意之一。
而且,看一下邮件列表,2010年前五个月只发布了七条消息(其中最早的消息已经有四个月未得到答复),整个2009年只有59条消息。我对此持怀疑态度,但这并不是看起来像一个充满活力的支持社区。
似乎有一个64位Windows的补丁(见 这里 在2010年的档案中)但是,再次,这似乎有问题,自2月以来没有答案,它只提到对MinGW的支持:
...这个补丁(有点粗糙,需要一些最后的清理和一些扩展到测试运行makefile以允许CROSS在这里)使pthread能够为x86_64-pc-mingw32目标构建。
这是 不 我将用于任务关键型软件的那种东西。
而且我知道你表示你对重新发明轮子不感兴趣,但是你可以很容易地实现多读卡器锁定和更基本原语的条件变量 - 我甚至有一个解决了写入饥饿问题的多读取器方案在几乎让我获得专利的方式(不是我同意软件专利,但我的雇主坚持认为它们很有价值)。
如果你拥有的唯一一个轮子有一半的轮辐缺失并且可怕地弯曲变形,你可能只需要重新考虑:-)
无论如何,Vista和Server2k8都引入了两者 条件变量 和 超薄读写器锁。 线程本地存储 自Win2k以来一直存在。我知道如果你仍然需要支持XP,那将无济于事,但我会展望未来。
而且由于您似乎已将可移植性定义为“仅限Windows”,并且您想要的所有功能在当前版本中都可用,我不确定我是否看到了坚持使用pthreads的优势。如果你想要POSIX的可移植性,是的,但这似乎并非如此。
很惊讶,没有人建议英特尔的线程构建模块。它们非常活跃并支持几乎所有内容,最新版本不到两周,如果您使用兼容的编译器,则提供C ++ 0x功能。
http://software.intel.com/en-us/intel-tbb/#sysreq