看视频教程的时候,老师说了这样一句话...我不是很理解.

[chaleaoch]

讲到 linux 多线程这块.

老师原话是这样的:"多线程还有一个好处, 我们后来做了一个这样的约定,一个新的库发布出来,默认就要支持多线程并发,如果一个函数不支持多线程并发,要在函数说明或者函数的名字中体现出来"

我的问题是 什么叫默认支持多线程并发? 是指 线程安全吗?

因为是录播...没法问.

[muntoya]

就是说函数能被并发调用不出问题，实现中没使用共享变量，或者使用时加了锁。

[Shura]

就是函数是线程安全的

[levenwindy]

新建 1 万个用户 while 循环，{}& 后台运行，你总不能开启一万个后台同时运行吧，得通过管道限制，简称并发

[CEBBCAT]

可重入性？

[neoblackcap]

居然是默认线程安全？我看 linux 社区都是默认不线程安全，线程安全都是会在文档里面写出来的呢

[Cbdy]

应该默认线程不安全，默认线程安全坑死你

[tedzhou1221]

我的感觉和 #5 差不多，一个功能或函数，线程安全不是最基本的吗？出现线程安全问题就是有 BUG

我有时候看那么教学视频，很多讲师，不能说是老师，他们大部分都是按流程说把内容说出来，有一些真的一知半解的。

[tedzhou1221]

我在 Java 里接触到，有的代码，为了说明功能是否是线程安全，都会在注释里说明，或者用 @ThreadSafe 之类的注解标明。但一般都是默认线程安全。

[nightwitch]

一般都是默认线程不安全。
线程安全的话一般实现都会带锁，这样单线程的用户就会付出额外的性能损失。

[buffzty]

函数名后面加_s 就是线程安全的，默认是不安全（快）的。
支持多线程并发是指多线程并发调用安全 你理解的没错，但是很多库并不是默认支持。

[no1xsyzy]

默认线程安全是不可能的。除非你用函数式语言或者，否则这一约定的实现是复杂而低效的。
尤其是 builder 一类的对象。因为在 build 的过程中常常是唯一写引用。
ponylang 里面可以用 variable capability 来保证写引用的排他性，函数可以要求只能在某些 cap （包括其 subcap ）上调用，线程安全靠编译器保证。

（在玩 pony，真的线程安全到吓人，而且没有锁，但是 cap 太麻烦了，成天 recover cap，跟锁心智负担其实差不多，debug 的一半时间在解决编译器报的 cap 问题。好处是没有竞态条件。

[Flymachine]

c++ STL 库 里一堆线程不安全的，包括最常用的 std::string 和 std::vector (或者说，多线程写入不安全)。
要求 C++库默认线程安全是不现实的。
C 就更不用说了。

但其他语言就不一定了。
比如 Rust， 没 unsafe 关键字的代码肯定是线程安全的，或许可以实现“默认线程安全”。
比如 PHP，CGI 运行主要是多进程，无所谓线程安全。
比如 Java 、Go 之类的，天生就是做高并发的网络应用。肯定愿意为了线程安全牺牲那点性能——否则为啥不上 C++。所以“默认线程安全”。

[Jirajine]

@Flymachine 是否有 unsafe 和是否线程安全有什么关系，没有 unsafe 代表你的程序不会 ub，用了 unsafe 代表需要自己 hold contract 。而标识一个类型是否线程安全的是 Send 和 Sync 这两个 trait 。
Java 、go 也一样，多数基本内置类型都是线程不安全的，线程安全需要加锁使用专门的 Atomic 类型。

[Flymachine]

@Jirajine Rust 这块应该是我理解有误了，感谢你的指导。
不过 Jave 和 Go 上，我的意思是他们会更重视线程安全而非性能。所以写开源库时可能会尽量保证“默认线程安全”。不是说做出来就是线程安全的...

[qbqbqbqb]

@Jirajine 我记得 Rust 的类型系统好像是对线程安全有一定保障的，会为自己写的 struct 自动推导 Send 和 Sync 的 trait，不用 unsafe 的话可以基本保证语义层面的安全（也就是说不会破坏内存中的对象；但是业务层面仍然有可能是不安全的）

[Jirajine]

@qbqbqbqb #15 Safe Rust 能够保障你的代码没有 data race，但不能（也不可能）保障没有 race condition 。