189 8069 5689
摘要： 一、前言 go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中CAS操作 二、CAS操作 go中的Cas操作与java中类似，都是借用了CPU提供的原子性指令来实现。
成都创新互联公司主要从事成都做网站、成都网站制作、成都外贸网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务桐庐,10多年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792
go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中CAS操作
go中的Cas操作与java中类似，都是借用了CPU提供的原子性指令来实现。CAS操作修改共享变量时候不需要对共享变量加锁，而是通过类似乐观锁的方式进行检查，本质还是不断的占用CPU 资源换取加锁带来的开销（比如上下文切换开销）。下面一个例子使用CAS来实现计数器
go中CAS操作具有原子性，在解决多线程操作共享变量安全上可以有效的减少使用锁所带来的开销，但是这是使用cpu资源做交换的。
我简单列举了并发编程的大纲，需要详细的私信“555”~~
实现指定个核心最大化使用，比如核心总数减一。
必要的库。
要使用的cpu数量，建议不全使用。
建立管道。
声明使用的cpu数。
建立互斥关系，本例中主要为了实现所有线程执行完后再执行后续程序。
创建cpu数减1个线程
后面每个任务结束时要done一个wg，这里根据具体情况加，是循环就在每个循环里加，保证后面能全部done即可
没有缓冲的、阻塞式的往管道传递字符串。
Wait是等所有线程都执行完，即增加的数字被全done掉。
关闭管道。
假设已有的函数是ReadLogs，在它的基础上加个Wg加函数名的新函数，我觉得这种方式不改变原有的，比较舒服。
大意是：循环从管道读取字符串，读不到了就跳出循环。
每个ReadLogs()之后加一个wg.Done()，相当于计数减一。
ReadLogs()就是要执行的任务，不再解释。
就是开指定个线程。
管道阻塞传值。
wg同步。
WgReadLogs循环接收。
最近三年，在工作中使用go开发了不少服务。深感go的便捷，以及它的runtime的复杂。我觉得需要定期的进行总结，因此决定写这篇文章，也许更准确的，应该叫笔记。
最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月，当然，和人手不足也有关系。而对于我个人而言，这个问题其实历时2年！这得从头说起。
在上一家公司的一个项目里，有一个服务做音视频数据的提取，这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件，这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式，问题的症状是服务运行一段时间后，不输出音视频数据。遗憾的是，由于疫情，项目停止，因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试，发现关键的语音处理服务运行一段时间后，会出现不拉流的情况，因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样，但同样用了go和c混编的方式。一开始，焦点就放在go的运行时上，觉得可能是go和c相互调用的方式不对。经过合理猜测，并用测试进行验证后，发现问题还是在第三方拉流的SDK上，它们的回调函数必须要快，否则有可能会阻塞它们的回调线程。当然，在go调用c的时候，如果耗时比较长，会对go的运行时造成一些副作用；在c回调go的时候，go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟，因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法，主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中，使用了gdb的gcore来生成堆栈；也搭建了灰度环境来进行压力测试，以及完善监控，这些都是解决方法的一部分。
正是这一问题，促使我更多的了解go的运行时。而我看得越多，越觉得go的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
直接嵌入c源代码到go代码里面
package main
/*
#include stdio.h
void myhello(int i) {
printf("Hello C: %d\n", i);
}
*/
import "C"
import "fmt"
func main() {
C.myhello(C.int(12))
fmt.Println("Hello Go");
}
需要注意的是C代码必须放在注释里面
import "C"语句和前面的C代码之间不能有空行
运行结果
$ go build main.go ./main
Hello C: 12
Hello Go
分开c代码到单独文件
嵌在一起代码结构不是很好看，很多人包括我，还是喜欢把两个分开，放在不同的文件里面，显得干净，go源文件里面是go的源代码，c源文件里面是c的源代码。
$ ls
hello.c hello.h main.go
$ cat hello.h
void hello(int);
$ cat hello.c
#include stdio.h
void hello(int i) {
printf("Hello C: %d\n", i);
}
$ cat main.go
package main
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go");
}
编译运行
$ go build ./main
Hello C: 12
Hello Go
编译成库文件
如果c文件比较多，最好还是能够编译成一个独立的库文件，然后go来调用库。
$ find mylib main
mylib
mylib/hello.h
mylib/hello.c
main
main/main.go
编译库文件
$ cd mylib
# gcc -fPIC -shared -o libhello.so hello.c
编译go程序
$ cd main
$ cat main.go
package main
// #cgo CFLAGS: -I../mylib
// #cgo LDFLAGS: -L../mylib -lhello
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go");
}
$ go build main.go
运行
$ export LD_LIBRARY_PATH=../mylib
$ ./main
Hello C: 12
Hello Go
在我们的例子中，库文件是编译成动态库的，main程序链接的时候也是采用的动态库
$ ldd main
linux-vdso.so.1 = (0x00007fffc7968000)
libhello.so = ../mylib/libhello.so (0x00007f513684c000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x00007f5136614000)
libc.so.6 = /lib64/libc.so.6 (0x00007f5136253000)
/lib64/ld-linux-x86-64.so.2 (0x000055d819227000)
理论上讲也是可以编译成整个一静态链接的可执行程序，由于我的机器上缺少静态链接的系统库，比如libc.a，所以只能编译成动态链接。