C标准库线程中的函数是否安全？
我在哪里可以获得明确的答案，我的memcpy （使用Ubuntu附带的eglibc实现）是否是线程安全的？ – 老实说，我真的没有在文档中找到明确的YES或NO。
顺便说一句，对于“线程安全”，我的意思是，只要同时复制字节的日期字节是安全的，同时使用memcpy是安全的。 至少在将只读数据复制到不重叠的区域时，这应该是可能的。
理想情况下，我希望在ARM编译器文档中看到本页底部的列表。
您可以在第2.9.1 Thread-Safety找到该列表： http ： //pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01
也就是说，这是posix不需要线程安全的函数列表。 所有其他function都必须是线程安全的。 Posix包括标准C库和典型的“unix”接口。 （完整列表， http：//pubs.opengroup.org/onlinepubs/9699919799/functions/contents.html ）
memcpy（）由posix指定，但不是2.9.1中列表的一部分，因此可以认为是线程安全的。
Linux上的各种环境至少试图尽可能地实现posix – 即使posix不需要它，linux / glibc上的函数也可能是线程安全的 – 尽管这很少被记录。 对于其他函数/库而不是posix所涵盖的内容，您将留下作者所记录的内容……
据我所知，posix将线程安全等同于重入，并保证没有内部数据争用。 但是，您负责可能的外部数据争用 – 例如保护自己不要使用可能同时更新的内存调用例如memcpy（）。
这取决于function，以及您如何使用它。
以memcpy为例，它通常是线程安全的， 如果你复制数据，其中源和目标都是私有的单个线程 。 如果您写入可由另一个线程读取/写入的数据，则它不再是线程安全的，您必须保护访问权限。
如果glibc函数不是线程安全的，那么手册页会这样说 ，并且（很可能）也是一个线程安全的变体，也记录在案。
例如，参见man strtok ：
大纲#include
char *strtok(char *str, const char *delim); char *strtok_r(char *str, const char *delim, char **saveptr);
_r （对于“reentrant”）是线程安全的变体。
遗憾的是，手册页没有养成说明函数是线程安全的习惯，但只是在问题时才提到线程安全性。
与所有函数一样，如果你给它一个指向共享资源的指针，那么它将变得线程不安全。 由你来处理锁定。