glibc终于支持C11的多线程库了。撒花

404了啊

可以打开了 【 在 q397273499 的大作中提到: 】 : 404了啊

为了创建线程改用C++是什么意思？之前不是有pthread线程库可以用吗？ 【 在 nuanyangyang 的大作中提到: 】 : https://lwn.net/Articles/761462/ : 自己看吧，真不容易。再也不用为了创建一个线程而改用C++了。

pthread有两个问题。 第一个是：它的语义定义得很模糊。C11有准确定义的并发memory model，可以用happens-before关系来讨论多线程程序读写内存的可见性，标准库里的组件也都用happens-before来定义语义，比如“创建线程”的动作happens before被创建的线程里的每一个动作；释放锁的操作happens before下一个获得锁的动作。而pthread则完全没有定义这种关系。比如，x是全局变量，初值是0。主线程先给它赋值1再创建子线程，子线程一开始就读x，请问子线程能保证读到1而不是0吗？C11可以，pthread不保证。 第二点是pthread仅适用于posix系统。还有很多非posix系统不能用pthread。比如windows，又比如一些嵌入式系统。那些嵌入式系统没有posix的操作系统，甚至根本没有操作系统。举个例子就是SEL4。这种系统上就只能依赖C标准库了。比如打开文件必须用fopen而不是open。FILE这个数据结构就已经在libc层面上实现成系统相关的了。由于glibc不支持threads.h，很多做嵌入式系统开发的人都换用别的libc实现，比如musl-c是支持C11的threads.h的。 glibc支持这个接口之后的影响就是现在多了一种跨平台的多线程编程工具。 【 在 stx 的大作中提到: 】 : 为了创建线程改用C++是什么意思？之前不是有pthread线程库可以用吗？

有多一个可以选择的线程库可以用，是好事情。 说到pthread，它的定义是宽松了些，但是这也给各个操作系统的线程实现和调度带来了很大的灵活性。当然灵活性大了，可移植性就差一些。 你举得例子，即便用pthread库，也需要创建完一个子线程，再执行子线程中的每个动作吧。后面提到的锁和全局变量的例子，线程同步（各种锁）不就是为了解决这个问题而准备的吗？ 你说的第二点。glibc是GNU C Library，是GNU旗下的C标准库。windows有自己的一套C运行库和线程库，跟glib没有关系。嵌入式我倒是没有仔细考虑，嵌入式上本身就有资源受限，不只是线程库有影响。还有，fopen是运行库的接口，而open是系统调用，这是大区别。C语言的运行库从某种程度上来讲是C语言的程序和不同操作系统平台之间的抽象层，它将不同的操作系统API抽象成相同的库函数。这样使用标准库的接口编程，就方便移植了。 【 在 nuanyangyang 的大作中提到: 】 : pthread有两个问题。 : 第一个是：它的语义定义得很模糊。C11有准确定义的并发memory model，可以用happens-before关系来讨论多线程程序读写内存的可见性，标准库里的组件也都用happens-before来定义语义，比如“创建线程”的动作happens before被创建的线程里的每一个动作；释放锁的操作happens before下一个获得锁的动作。而pthread则完全没有定义这种关系。比如，x是全局变量，初值是0。主线程先给它赋值1再创建子线程，子线程一开始就读x，请问子线程能保证读到1而不是0吗？C11可以，pthread不保证。 : 第二点是pthread仅适用于posix系统。还有很多非posix系统不能用pthread。比如windows，又比如一些嵌入式系统。那些嵌入式系统没有posix的操作系统，甚至根本没有操作系统。举个例子就是SEL4。这种系统上就只能依赖C标准库了。比如打开文件必须用fopen而不是open。FILE这个数据结构就已经在libc层面上实现成系统相关的了。由于glibc不支持threads.h，很多做嵌入式系统开发的人都换用别的libc实现，比如musl-c是支持C11的threads.h的。 : ...................

用论坛app打开含有大写字母的大小写敏感链接就会404，这个是论坛app的一个bug(典型例子如微信链接) 【 在 q397273499 (【加菲猫粉丝团】飞走啦 都飞走啦) 的大作中提到: 】 : 404了啊

嗯，想知道暖神做开发多久了，如何练得这一身绝技

这里有两个东西需要说一说 : 说到pthread，它的定义是宽松了些，但是这也给各个操作系统的线程实现和调度带来了很大的灵活性。当然灵活性大了，可移植性就差一些。 是这样。定义宽松，提供灵活性，但我认为这不是一件好事。C语言也是“定义宽松”，宽松到，short、int、long、long long有多大，没有定义；有符号整数溢出会发生什么，没有规定；是否使用2的补码，没有规定；整数除以0会发生什么，没有定义。这么基本的操作都没有定义，程序员没有办法写出一个程序，在所有的平台上意思都相同，而总是“我写的程序只有在xxx平台上才是我想的意思”。就像你说的，不可移植。 : 你举得例子，即便用pthread库，也需要创建完一个子线程，再执行子线程中的每个动作吧。后面提到的锁和全局变量的例子，线程同步（各种锁）不就是为了解决这个问题而准备的吗？ 创建完一个子线程，再执行子线程中的每个动作。这个“再”字用得非常好，就是“happens-before”的意思。举个例子： struct CommonStruct { int value1; char value2; double value3; } common_struct; int main() { common_struct.value1 = 42; common_struct.value2 = 'a'; common_struct.value3 = 3.14; pthread_t thr; pthread_create(&thr, NULL, thr_start, NULL); pthread_join(thr, NULL); } void* thr_start(void* unused) { assert(common_struct.value1 == 42 && "The assignment in the main thread does not happen before this thread."); // may fail (in theory) return NULL; } 程序员想，“创建线程之前初始化，线程里面可以读到”，这么简单的同步方式应该不需要锁的吧？之所以会产生这种结果，可能是CPU里对内存操作的重排序，也可能是编译器的优化。以前多核CPU不流行的时候还好说，标准也不怎么去规定；但这种并行设备流行了，这种匪夷所思的现象也不再罕见，就需要一个标准来确切地规定这个语义了。C11规定的“创建线程之前的动作happens before新线程里所有的动作”这一条，起码可以保证上例的assert不会失败。像pthread一样没有这个规定的话，用锁是可以，锁只是好多种同步方式中的一种，但上述的happens before关系更方便，而且没有性能损耗。还有各种无锁同步，这就需要语言的规范了（C11内存模型），pthread无法涉足这个领域。C11之前就只能靠各个编译器的私有扩展，或者手写汇编了。 所以，还是像Hans Boehm说的那样：Threads cannot be implemented as a library. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf 【 在 stx 的大作中提到: 】 : 有多一个可以选择的线程库可以用，是好事情。 : ...................

定义宽松这个话题，见仁见智。我说的是移植性差一些，不是不可移植。大部分这种实现差异，在移植的时候都可以通过条件编译的宏来判断解决。 你说的第二点，我了解的没有那么多，无法仔细分辨。不过，我同意你说的一些观点，过去定义的标准如果不能够即时适应现在的机器（并行计算，多核流行）变化，那么这个标准放在现在来看就是有问题的。 你发的论文没有来得及看，有时间的话会过一遍。HP lab的论文，说个有意思的事情，HP NonStop服务器上的他们公司自己实现的线程库真是差的一塌糊涂。 【 在 nuanyangyang 的大作中提到: 】 : 这里有两个东西需要说一说 : : 是这样。定义宽松，提供灵活性，但我认为这不是一件好事。C语言也是“定义宽松”，宽松到，short、int、long、long long有多大，没有定义；有符号整数溢出会发生什么，没有规定；是否使用2的补码，没有规定；整数除以0会发生什么，没有定义。这么基本的操作都没有定义，程序员没有办法写出一个程序，在所有的平台上意思都相同，而总是“我写的程序只有在xxx平台上才是我想的意思”。就像你说的，不可移植。 : ...................