[读书笔记] go 语言如何处理系统调用

上一篇博客主要是讲如何避免在高并发下使用太多系统线程或进程,但如果仅仅是减少了线程数,CPU利用率本身没有上来,那么系统的容量很低,那么仍然无法达到高并发的目的。

通常情况下,我们会设置线程数等于CPU数,充分利用CPU就等价于如何让线程一直工作,避免把时间浪费在等待系统调用返回上,从而提高系统容量。

很多 linux 平台下的异步框架都基于 epoll 来设计,但 epoll 本身只支持 fd, 也就是说能很好的支持文件IO以及socket, 但对于其他系统调用则无法处理,在调用时仍然会造成堵塞,比如 creat, unlink等等。在大部分情况下,能对文件IO和socket进行异步处理已经能满足我们的需求,比如 libevent,  Java 的 NIO 都只提供了这些支持。

node.js 支持得更多一些,具体可以参考他的 fs 模块 ,对大量的系统调用同时提供了同步调用和异步调用的接口。

go 语言在编程的时候无需开发者对系统调用做特殊处理,我相信他在内部做了一些处理来支持他的高并发特性,但毕竟要眼见为实。

go 语言与系统调用的模块放在 syscall package,并在上面封装出了 "os", "time", "net" 等模块,并且建议直接使用后面的模块,单从 syscall 里边函数的接口来看,看不到任何异步非阻塞的迹象,只能从源代码的角度来分析。

syscall package 的源码位于 src/pkg/syscall/syscall_linux.go  等文件,不过里边的函数都是简单地对更底层函数的一个包装,比如

//sys   open(path string, mode int, perm uint32) (fd int, errno int)
func Open(path string, mode int, perm uint32) (fd int, errno int) {
return open(path, mode|O_LARGEFILE, perm)
}

真正按异步方式的代码位于 src/pkg/syscall/zsyscall_linux_amd64.go 这样的文件里,这个文件是由上面的文件编译而成的,范例如下

func open(path string, mode int, perm uint32) (fd int, errno int) {
r0, _, e1 := Syscall(SYS_OPEN, uintptr(unsafe.Pointer(StringBytePtr(path))), uintptr(mode), uintptr(perm))
fd = int(r0)
errno = int(e1)
return
}

Syscall 的定义位于 src/pkg/syscall/asm_linux_amd64.s, 是用汇编写成的,不过我不懂汇编(泪)

TEXT    ·Syscall(SB),7,$0
CALL runtime·entersyscall(SB)
MOVQ 16(SP), DI
MOVQ 24(SP), SI
MOVQ 32(SP), DX
MOVQ $0, R10
MOVQ $0, R8
MOVQ $0, R9
MOVQ 8(SP), AX // syscall entry
SYSCALL
CMPQ AX, $0xfffffffffffff001
JLS ok
MOVQ $-1, 40(SP) // r1
MOVQ $0, 48(SP) // r2
NEGQ AX
MOVQ AX, 56(SP) // errno
CALL runtime·exitsyscall(SB)
RET
ok:
MOVQ AX, 40(SP) // r1
MOVQ DX, 48(SP) // r2
MOVQ $0, 56(SP) // errno
CALL runtime·exitsyscall(SB)
RET

其中 runtime·entersyscall 和 runtime·exitsyscall 位于 src/pkg/runtime/proc.c

分析不下去了,不过能确认的是, go 语言确实做了什么,避免了系统调用堵塞线程,保证了程序能充分使用 CPU。

posted @ 2011-10-07 22:07 LI Daobing 阅读(...) 评论(...) 编辑 收藏