1
00:00:05,840 --> 00:00:08,630
In this lecture, I want to talk about poisoning.

2
00:00:09,140 --> 00:00:13,880
We learned a lot in the previous lecture about new taxes and the benefits that they give us.

3
00:00:13,880 --> 00:00:18,980
But you might have been wondering what would happen if the thread panicked while holding the lock.

4
00:00:19,250 --> 00:00:22,760
When that occurs, our mutex has became poisoned.

5
00:00:23,030 --> 00:00:29,630
This is obviously very undesirable because when this happens, all other threads are unable to access

6
00:00:29,630 --> 00:00:32,090
the data since it is likely tainted.

7
00:00:33,050 --> 00:00:42,800
So I went ahead and created an example here and I instantiated a new atomic reference counted mutex

8
00:00:42,800 --> 00:00:47,390
and then I also cloned it into the lock two variable.

9
00:00:47,390 --> 00:00:56,000
And now remember, our clone produces a new arc instance which points to the same allocation on the

10
00:00:56,000 --> 00:00:58,310
heap as the source arc.

11
00:00:59,150 --> 00:01:02,800
But it it increments its reference count.

12
00:01:02,810 --> 00:01:09,980
So this arc is pointing to this one up here.

13
00:01:10,730 --> 00:01:13,430
So inside here, we're going to take.

14
00:01:14,760 --> 00:01:16,980
BLOCK and then we're going to panic.

15
00:01:17,850 --> 00:01:24,450
So up here, when we acquire the lock, our lock is currently completely acceptable.

16
00:01:24,480 --> 00:01:34,650
But calling the panic macro here, while this thread was holding the lock, our mutex is now poisoned

17
00:01:35,250 --> 00:01:44,820
and for us to recover from this, we can do a match statement and we can try to match on what gets returned

18
00:01:44,820 --> 00:01:52,410
when we try to access the lock that became poisoned and.

19
00:01:53,300 --> 00:01:55,390
If Oak is return, then that's good.

20
00:01:55,400 --> 00:01:57,890
We get our value back.

21
00:01:58,130 --> 00:02:07,460
But if it's poisoned then we can call into inner to recover the mutex in the data inside of it.

22
00:02:08,150 --> 00:02:17,270
And when we're able to do that, then we're able to access the data as normal and we will have our mutex

23
00:02:17,270 --> 00:02:17,780
back.

24
00:02:17,810 --> 00:02:25,670
And to demonstrate this, I can run this program and we see that I have printed out the value one.

25
00:02:26,060 --> 00:02:30,170
Well, when I created the new mutex, our value was zero.

26
00:02:30,650 --> 00:02:32,390
We poisoned it here.

27
00:02:32,750 --> 00:02:41,900
And then in our match statement, we called into enter on it in order to recover it and then ID referenced

28
00:02:41,900 --> 00:02:43,450
the value inside of it.

29
00:02:43,460 --> 00:02:47,000
So here is basically zero plus zero.

30
00:02:47,960 --> 00:02:54,850
Uh, zero plus one, and then we return one back and that is what was outputted back.

31
00:02:54,860 --> 00:03:04,700
So it's important to have this match statement running in the event that you think one of your threads

32
00:03:04,700 --> 00:03:07,520
might panic while holding the lock.

33
00:03:07,520 --> 00:03:09,950
So it's just something for you to think about.