ioutil.Discard 这个 io.writer 是线程安全的吗

文档没写就看源码呗

ioutil.Discard 对象本身没有保存什么信息，进去的东西都被丢弃了

丢弃的数据需要什么线程安全？

假设楼主 writer 并发写的话，最终顺序是啥？

https://golang.org/src/io/ioutil/ioutil.go

从 122 行开始看，
type devNull int
var Discard io.Writer = devNull(0)

没有 data，何来 data race ？

@sagaxu 受教

就是 /dev/null

@sagaxu
1. 没有 data 也可以有 race，data race 是 race condition 的子集
2. 这个事要从 144 行来看，ioutil.Discard 被专门做成了线程安全的
3. ioutil.Discard 曾经不是线程安全的，还被当案例写下来了。https://blog.golang.org/race-detector

@CRVV 在多线程并发上除了 data race 还有什么 race ？或者说软件开发上，还有别的导致不线程安全的 race?

@sagaxu
文件的 close 和 open 之间可以有 race，这个和常见的 data race 是两回事

Node.js 里，如果写
console.log('exit')
process.exit()
前面的写操作是异步的，所以这两行之间有 race

@CRVV 串行执行的时候，你 close 掉文件再写入一样有问题，这已经不是 race 了，是 data dependency。

@sagaxu
不是先 close 再 read 的问题
是 close 和 open 的问题
我指的是 https://github.com/golang/go/issues/7970

@CRVV 你举的先 close 再 open 例子就是典型的 data race

@CRVV 感谢，非常感谢

@CRVV

f.fd = -1 没有 happens-before close(fd)，所以才引发了这个问题，在 Java Language Specification 里，这种因为 order 引发的错误，不管是代码写错还是编译器重排序引起，都称为 data race。

也有只把 data race 定义为 memory access 引发问题的，比如你给的那个博客。

@sagaxu

https://docs.oracle.com/javase/specs/jls/se9/html/jls-17.html#jls-17.4.5
When a program contains two conflicting accesses (§17.4.1) that are not ordered by a happens-before relationship, it is said to contain a data race.

https://docs.oracle.com/javase/specs/jls/se9/html/jls-17.html#jls-17.4.1
Two accesses to (reads of or writes to) the same variable are said to be conflicting if at least one of the accesses is a write.

Java Language Specification 也把 data race 定义为 memory access

@CRVV 难道说这个 f.fd 不是共享的 instance field?

Table 17.4-B. Surprising results caused by statement reordering - valid compiler transformation

重排序引发的问题也当成 data race 的案例解释了

@sagaxu #17 这里的重排 是值 CPU 乱序指令 执行吗？