- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章Go语言并发编程之互斥锁Mutex和读写锁RWMutex由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
在并发编程中,多个Goroutine访问同一块内存资源时可能会出现竞态条件,我们需要在临界区中使用适当的同步操作来以避免竞态条件。Go 语言中提供了很多同步工具,本文将介绍互斥锁Mutex和读写锁RWMutex的使用方法.
Go 语言的同步工具主要由 sync 包提供,互斥锁 (Mutex) 与读写锁 (RWMutex) 就是sync 包中的方法.
互斥锁可以用来保护一个临界区,保证同一时刻只有一个 goroutine 处于该临界区内。主要包括锁定(Lock方法)和解锁(Unlock方法)两个操作,首先对进入临界区的goroutine进行锁定,离开时进行解锁.
使用互斥锁 (Mutex)时要注意以下几点:
deadlock
);sync.Mutex
类型属于值类型,将它传给一个函数时,会产生一个副本,在函数中对锁的操作不会影响原锁总之,一个互斥锁只用来保护一个临界区,加锁后记得解锁,对于每一个锁定操作,都要有且只有一个对应的解锁操作,也就是加锁和解锁要成对出现,最保险的做法时使用 defer语句 解锁.
下面的代码模拟取钱和存钱操作:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
package main
import
(
"flag"
"fmt"
"sync"
)
var (
mutex
sync
.Mutex
balance int
protecting uint
//
是否加锁
sign =
make
(chan struct{}, 10)
//
通道,用于等待所有goroutine
)
//
存钱
func deposit(value int) {
defer func() {
sign <- struct{}{}
}()
if
protecting == 1 {
mutex.Lock()
defer mutex.Unlock()
}
fmt
.Printf(
"余额: %d\n"
, balance)
balance += value
fmt
.Printf(
"存 %d 后的余额: %d\n"
, value, balance)
fmt
.Println()
}
//
取钱
func withdraw(value int) {
defer func() {
sign <- struct{}{}
}()
if
protecting == 1 {
mutex.Lock()
defer mutex.Unlock()
}
fmt
.Printf(
"余额: %d\n"
, balance)
balance -= value
fmt
.Printf(
"取 %d 后的余额: %d\n"
, value, balance)
fmt
.Println()
}
func main() {
for
i:=0; i < 5; i++ {
go withdraw(500)
//
取500
go deposit(500)
//
存500
}
for
i := 0; i < 10; i++ {
<-sign
}
fmt
.Printf(
"当前余额: %d\n"
, balance)
}
func init() {
balance = 1000
//
初始账户余额为1000
flag.UintVar(&protecting,
"protecting"
, 0,
"是否加锁,0表示不加锁,1表示加锁"
)
}
|
上面的代码中,使用了通道来让主 goroutine 等待其他 goroutine 运行结束,每个子goroutine在运行结束之前向通道发送一个元素,主 goroutine 在最后从这个通道接收元素,接收次数与子goroutine个数相同。接收完后就会退出主goroutine.
代码使用协程实现多次(5次)对一个账户进行存钱和取钱的操作,先来看不加锁的情况:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
余额: 1000
存 500 后的余额: 1500
余额: 1000
取 500 后的余额: 1000
余额: 1000
存 500 后的余额: 1500
余额: 1000
取 500 后的余额: 1000
余额: 1000
存 500 后的余额: 1500
余额: 1000
取 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 1000
存 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 1000
存 500 后的余额: 1000
当前余额: 1000
|
可以看到出现了混乱,比如第二次1000的余额取500后还是1000,这种对同一资源的竞争出现了竞态条件(Race Condition).
下面来看加锁的执行结果:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
存 500 后的余额: 1500
余额: 1500
取 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
当前余额: 1000
|
加锁后就正常了.
下面介绍更细化的互斥锁:读/写互斥锁RWMutex.
读/写互斥锁RWMutex包含了读锁和写锁,分别对共享资源的“读操作”和“写操作”进行保护。sync.RWMutex类型中的Lock方法和Unlock方法分别用于对写锁进行锁定和解锁,而它的RLock方法和RUnlock方法则分别用于对读锁进行锁定和解锁.
有了互斥锁Mutex,为什么还需要读写锁呢?因为在很多并发操作中,并发读取占比很大,写操作相对较少,读写锁可以并发读取,这样可以提供服务性能。读写锁具有以下特征:
。
读写锁 | 读锁 | 写锁 |
---|---|---|
读锁 | Yes | No |
写锁 | No | No |
。
也就是说, 。
goroutine
不能进行写操作。换句话说就是读写操作和写写操作不能并行执行,也就是读写互斥;在使用读写锁时,还需要注意:
改写前面的取钱和存钱操作,添加查询余额的方法:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
package main
import
(
"fmt"
"sync"
)
//
account 代表计数器。
type
account struct {
num uint
//
操作次数
balance int
//
余额
rwMu *
sync
.RWMutex
//
读写锁
}
var sign =
make
(chan struct{}, 15)
//
通道,用于等待所有goroutine
//
查看余额:使用读锁
func (c *account) check() {
defer func() {
sign <- struct{}{}
}()
c.rwMu.RLock()
defer c.rwMu.RUnlock()
fmt
.Printf(
"%d 次操作后的余额: %d\n"
, c.num, c.balance)
}
//
存钱:写锁
func (c *account) deposit(value int) {
defer func() {
sign <- struct{}{}
}()
c.rwMu.Lock()
defer c.rwMu.Unlock()
fmt
.Printf(
"余额: %d\n"
, c.balance)
c.num += 1
c.balance += value
fmt
.Printf(
"存 %d 后的余额: %d\n"
, value, c.balance)
fmt
.Println()
}
//
取钱:写锁
func (c *account) withdraw(value int) {
defer func() {
sign <- struct{}{}
}()
c.rwMu.Lock()
defer c.rwMu.Unlock()
fmt
.Printf(
"余额: %d\n"
, c.balance)
c.num += 1
c.balance -= value
fmt
.Printf(
"取 %d 后的余额: %d\n"
, value, c.balance)
fmt
.Println()
}
func main() {
c := account{0, 1000, new(
sync
.RWMutex)}
for
i:=0; i < 5; i++ {
go c.withdraw(500)
//
取500
go c.deposit(500)
//
存500
go c.check()
}
for
i := 0; i < 15; i++ {
<-sign
}
fmt
.Printf(
"%d 次操作后的余额: %d\n"
, c.num, c.balance)
}
|
执行结果:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
余额: 1000
取 500 后的余额: 500
1 次操作后的余额: 500
1 次操作后的余额: 500
1 次操作后的余额: 500
1 次操作后的余额: 500
1 次操作后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
存 500 后的余额: 1500
余额: 1500
取 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
余额: 1000
取 500 后的余额: 500
余额: 500
存 500 后的余额: 1000
10 次操作后的余额: 1000
|
读写锁和互斥锁的不同之处在于读写锁把对共享资源的读操作和写操作分开了,可以实现更复杂的访问控制.
总结:
读写锁也是一种互斥锁,它是互斥锁的扩展。在使用时需要注意:
到此这篇关于Go语言并发编程之互斥锁Mutex和读写锁RWMutex的文章就介绍到这了,更多相关Go语言 Mutex RWMutex内容请搜索我以前的文章或继续浏览下面的相关文章希望大家以后多多支持我! 。
原文链接:https://www.tuicool.com/articles/YFnIJz7 。
最后此篇关于Go语言并发编程之互斥锁Mutex和读写锁RWMutex的文章就讲到这里了,如果你想了解更多关于Go语言并发编程之互斥锁Mutex和读写锁RWMutex的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我需要在一个函数内锁定一个 std::map 和两个 boost::multimaps 的操作,因为我们有线程试图访问该函数(以及映射)。 我计划使用“std::mutex mutex_var”来保护
已关闭。这个问题是 off-topic 。目前不接受答案。 想要改进这个问题吗? Update the question所以它是on-topic用于堆栈溢出。 已关闭11 年前。 Improve th
或不同的标题: 为什么处置获得的 Mutex 会破坏它? 我有以下代码,真正的代码在几个方法之间产生,并在这个方法休眠的地方做事: bool createdNew; u
如何测量互斥量、信号量或 futex 的延迟?我的意思是两个事件之间的延迟:解锁先前锁定的互斥体和锁定该互斥体。有两种情况:当所有线程/进程都在同一个 CPU 上时(重新调度线程需要多长时间)以及当第
我执行了以下程序,其中我创建了 100 个线程并发执行。请注意这是一个示例程序。我知道下面的程序不需要多线程,但我的目的是测试互斥量。 class ThreadPool{ public:
我有创建多个线程的代码,所有线程都尝试将信息记录在一个文件中我尝试使用互斥锁来登录文件,但是当我使用 Mutex() 和 Mutex(true or false, "name") 对象时,我得到了不同
我正在研究 Rust 示例。有这段代码: fn new(name: &str, left: usize, right: usize) -> Philosopher { Philosopher
我正在实现一个基于 std::queue 的 C++ 消息队列。 因为我需要 popers 在空队列上等待,所以我考虑使用 mutex 进行互斥,并使用 cond 在空队列上挂起线程,就像 glib
在golang中,sync.Mutex Lock和Unlock是usaul操作,但是Lock和defer Unlock的正确顺序是什么? mu.Lock() defer mu.Unlock() 或 d
在 Go 中,我们可以使用: type Data struct { lock *sync.Mutex } 或 type Data struct { lock sync.Mutex
我尝试摆脱代码中的一些 boost 依赖项,转而使用新的 C++11 功能 (Visual Studio 2013)。 在我的一个组件中,我使用了 boost::mutex与 boost::lock_
我正在使用 scoped_lock 和 mutex 来实现 BlockingQueue posted in a different SO question 的一个版本, 但在 boost 中有多个不同
我在互斥锁析构函数中遇到了上述错误。由于错误可能是由于互斥锁在销毁过程中处于锁定状态,所以我创建了一个新的互斥锁类,它继承自 boost:mutex。这是为了确保互斥锁在销毁期间解锁。但是,仍然会出现
今天写了一些代码来测试mutex的性能。 这是 boost(1.54) 版本,在 vs2010 上编译并进行了 O2 优化: boost::mutex m; auto start = boost::c
我不知道我没有做什么,但我根本无法让自己的调试器保存正在调试的应用程序的“Mutex Owned”或“Mutex Free”信息。 如果我按如下方式调用它,CDB 就可以正常工作: cdb -pn
还没有网上的例子来生动地演示这一点。在 http://en.cppreference.com/w/cpp/header/shared_mutex 看到了一个例子但目前还不清楚。有人可以帮忙吗? 最佳答
我有两个用例。 A.我想同步访问两个线程的队列。 B.我想同步两个线程对队列的访问并使用条件变量,因为其中一个线程将等待另一个线程将内容存储到队列中。 对于用例 A,我看到了使用 std::lock_
我编写了一个小型 Go 库 ( go-patan ),用于收集某些变量的运行最小值/最大值/平均值/标准偏差。我将它与等效的 Java 实现 ( patan ) 进行了比较,令我惊讶的是 Java 实
我想知道这两者之间的区别是什么 boost::timed_mutex _mutex; if(_mutex.timed_lock(boost::get_system_time() + boost::po
我正在尝试将 dyn 特征存储在 Arc>>>> 中,但是由于某种原因它不起作用 use std::sync::{Arc, Mutex}; trait A{} struct B{} impl A fo
我是一名优秀的程序员,十分优秀!