1

00:00:00,990  -->  00:00:07,440
Hi there in this lesson let's see how we can avoid the race condition which we saw in the previous lesson

2

00:00:07,440  -->  00:00:08,070
.

3

00:00:08,190  -->  00:00:10,410
It was because the class was not correct.

4

00:00:10,450  -->  00:00:18,360
If this is the make with dogmatic and visit that this method needs to execute as a single economic unit

5

00:00:18,720  -->  00:00:23,410
in order to avoid the undesirable outcome of a drawing.

6

00:00:23,790  -->  00:00:30,450
And for that we can use the jealous berichten locking mechanism called synchronization on going off

7

00:00:30,510  -->  00:00:36,360
and going to the agent is to protect critical data which is shared and also mutable like the balance

8

00:00:36,360  -->  00:00:39,380
instance variable in our example.

9

00:00:39,480  -->  00:00:47,820
In fact we also how items 5:54 from Effective Java which is synchronize access to shared data and synchronization

10

00:00:48,240  -->  00:00:55,650
ensures data protection by dis allowing threats from interfering with each other when we're talking

11

00:00:55,650  -->  00:01:01,410
about synchronization we are talking about a block of code which needs to be synchronized on this block

12

00:01:01,410  -->  00:01:02,000
of code.

13

00:01:02,080  -->  00:01:08,160
Can one or more statements on a synchronized block basically contains parts.

14

00:01:08,280  -->  00:01:15,000
One is a lock which acts like a real lock and we will look at that and the other is a block of code

15

00:01:15,120  -->  00:01:21,090
which needs to be guarded by this lock on this block of code would be the critical data that needs to

16

00:01:21,090  -->  00:01:27,090
be protected like the checking of the balance and the subsequent New Balance computation in our bank

17

00:01:27,090  -->  00:01:33,850
account example and that lock here is nothing but a reference to an object.

18

00:01:34,050  -->  00:01:39,270
And here is how a synchronized block looks like we will have the synchronized keyword followed by an

19

00:01:39,360  -->  00:01:45,630
object reference in the parenthesis which acts as a lock and it is followed by a block of code and Caly

20

00:01:45,660  -->  00:01:48,150
basis.

21

00:01:48,150  -->  00:01:49,350
And here is an example.

22

00:01:49,560  -->  00:01:53,090
Here we have them a third go which includes a synchronized block.

23

00:01:53,430  -->  00:02:00,270
The lock is simply that this reference so reference to current object is serving as the lock on inside

24

00:02:00,270  -->  00:02:01,220
the synchronized block.

25

00:02:01,320  -->  00:02:03,220
We have the critical stuff on outside.

26

00:02:03,240  -->  00:02:06,300
We have the non-critical stuff.

27

00:02:06,340  -->  00:02:08,640
And let's see how locks work.

28

00:02:08,640  -->  00:02:16,710
Always keep in mind that every object has a single lock and every thread and during a synchronized block

29

00:02:17,010  -->  00:02:24,450
will automatically acquire the lock and will release it either upon exiting the synchronized block or

30

00:02:24,450  -->  00:02:28,950
if an exception is generated within the synchronized block.

31

00:02:29,170  -->  00:02:35,100
An important thing here to note is that at most one threat can why the objects lock.

32

00:02:35,160  -->  00:02:40,940
As mentioned earlier an object has only a single lock on that block cannot be shared across the decks

33

00:02:40,940  -->  00:02:41,380
.

34

00:02:41,760  -->  00:02:46,250
This way only one thread gets to manipulate the critical data.

35

00:02:47,040  -->  00:02:52,350
So if a thread wants to enter a synchronized block but the lock is unavailable which means that some

36

00:02:52,350  -->  00:02:54,460
other thread has already acquired it.

37

00:02:54,510  -->  00:02:57,670
In this case the thread goes into the blocked state.

38

00:02:58,020  -->  00:03:01,730
So the template for the lock to be released by the current threat.

39

00:03:01,880  -->  00:03:07,290
And once that lock is available again it put it quite it and then would enter the synchronized block

40

00:03:07,300  -->  00:03:07,700
.

41

00:03:08,490  -->  00:03:11,440
Look at more than one third could be waiting for the lock.

42

00:03:11,760  -->  00:03:18,900
In that case once the lock is available only one of them will get to it an it ular will decide who that

43

00:03:18,900  -->  00:03:26,790
lucky protests and this building locks associated with objects are called as intrinsic or mounted deadlocks

44

00:03:26,790  -->  00:03:28,000
.

45

00:03:28,020  -->  00:03:33,330
So that's the thing every object has a lock that needs to be acquired before entering gringas synchronized

46

00:03:33,330  -->  00:03:36,330
block which protects critical data.

47

00:03:36,330  -->  00:03:41,760
This way we cannot have race conditions as only one thread gets to use the entire synchronized block

48

00:03:43,770  -->  00:03:45,410
next to synchronize method.

49

00:03:45,450  -->  00:03:50,820
It is simply a shorthand for a synchronized block and we simply use the key word synchronized in the

50

00:03:50,820  -->  00:03:59,100
method declaration and with that the matter is guarded by a lock on here the lock is simply the object

51

00:03:59,100  -->  00:04:01,690
on which the method is invoked.

52

00:04:01,940  -->  00:04:06,910
At this Bangkit called object does not have a race condition and this direct.

53

00:04:08,520  -->  00:04:17,110
As mentioned earlier every object has a single lock so locks are but objects are not Marmelade.

54

00:04:17,520  -->  00:04:25,350
So what it means is that if one threat has acquired an object's lock then no other thread Ginter any

55

00:04:25,350  -->  00:04:31,200
of the objects synchronized methods here the lock would have been acquired by entering a synchronized

56

00:04:31,200  -->  00:04:34,430
block or by entering this method.

57

00:04:34,780  -->  00:04:37,260
And it is important to remember at this particular point.

58

00:04:37,400  -->  00:04:39,810
And let's also do a bit of shooting here.

59

00:04:39,810  -->  00:04:42,720
It will be one of the quiz questions too.

60

00:04:42,720  -->  00:04:48,270
So keep that in mind and you may even be asked about it in an interview.

61

00:04:48,690  -->  00:04:55,080
And here is another quick question on a potential question to a third going under any unsynchronized

62

00:04:55,080  -->  00:04:56,490
method of the object.

63

00:04:56,490  -->  00:05:02,810
Even if Glock is already acquired by some other threat so not a strict sions with unsynchronized amateurs

64

00:05:03,200  -->  00:05:06,810
as they are do not build with critical data.

65

00:05:06,840  -->  00:05:08,410
And here is an interesting one.

66

00:05:08,450  -->  00:05:13,260
It's tactics and Grise methods use class object as a lock.

67

00:05:13,350  -->  00:05:21,530
So every class has a single lock on every object also has a single lock Soviet using synchronization

68

00:05:21,940  -->  00:05:27,710
to coordinate access to shared variables shit notably variables but there are a couple of important

69

00:05:27,710  -->  00:05:29,030
things we need to know.

70

00:05:29,060  -->  00:05:36,170
When it comes to coordinating access to shared variables crusting is that we need to use synchronization

71

00:05:36,320  -->  00:05:36,940
everywhere.

72

00:05:36,960  -->  00:05:44,430
The is just one instance that's going to get a bank account plus we have the make with Dolemite that

73

00:05:44,480  -->  00:05:46,000
which is synchronized.

74

00:05:46,010  -->  00:05:50,390
Now let's see if you also have this get automatic get balance between it and the balance around you

75

00:05:50,720  -->  00:05:51,160
.

76

00:05:51,540  -->  00:05:53,930
Now let's say John's track is inside.

77

00:05:53,930  -->  00:05:57,810
Make the document that trying to $.75.

78

00:05:58,070  -->  00:06:02,880
Let's say there is enough balance on the new balance of dollar 25 if it's competitor.

79

00:06:03,350  -->  00:06:09,350
Let's also say that after the New Balances computer but before John Street exits to make with dogmatic

80

00:06:09,490  -->  00:06:15,800
on Anita outstretched accesses get balanced about that which is not synchronized in this case.

81

00:06:15,860  -->  00:06:22,190
There is a chance that it thread will still get a value of dollar hundred rather than the new balance

82

00:06:22,190  -->  00:06:23,780
off dollar 25.

83

00:06:24,650  -->  00:06:25,770
It means you dollar.

84

00:06:25,760  -->  00:06:28,050
Only if I do but there is no guarantee.

85

00:06:28,700  -->  00:06:33,580
So basically in a multi-threaded program if it dragged right so gladly you into a variable.

86

00:06:33,890  -->  00:06:40,010
There is no guarantee that the renewables new value will be visible to another thread trying to read

87

00:06:40,010  -->  00:06:46,510
that variable's value and it has been kept that way mainly for performance results as such into strict

88

00:06:46,520  -->  00:06:50,170
coordination can harm the performance.

89

00:06:50,270  -->  00:06:56,150
We may discuss why it is that way but for now it is good enough to know that it's got something to do

90

00:06:56,360  -->  00:07:03,800
with romance but if we want to get into here that it does today we'll see the most recent value of balance

91

00:07:04,260  -->  00:07:05,200
that maybe are better.

92

00:07:05,210  -->  00:07:11,000
But don't sell it then we need to synchronize the get balance method as well as synchronized.

93

00:07:11,030  -->  00:07:17,360
Any other place where balance variable is used and this is also discussed in item 5:54 which was mentioned

94

00:07:17,360  -->  00:07:18,940
earlier.

95

00:07:19,160  -->  00:07:26,770
So synchronization means not only just mutual exclusion but also reliable communication between threats

96

00:07:27,120  -->  00:07:27,780
.

97

00:07:28,250  -->  00:07:33,740
And we may get back to this in a follow up lesson well there are some alternative ways to also achieve

98

00:07:33,740  -->  00:07:37,060
reliable communication.

99

00:07:37,060  -->  00:07:43,300
Now the second important thing to note about coordinating access to shared multiple with is that always

100

00:07:43,400  -->  00:07:48,230
use the same lock when guarding the CMS shared multiple variables.

101

00:07:48,560  -->  00:07:53,600
That is do not guard a variable using one lock at one place and using some other lock at some other

102

00:07:53,600  -->  00:07:55,870
place.

103

00:07:55,950  -->  00:07:57,180
And here is an example.

104

00:07:57,380  -->  00:07:59,750
So once again it is a bank account example.

105

00:07:59,870  -->  00:08:07,130
And we have the synchronized make with dogmatics and we also know how that method called deposit which

106

00:08:07,130  -->  00:08:13,460
actually uses a synchronized block that is guarding the same balance variable as some deposit is being

107

00:08:13,490  -->  00:08:14,350
added.

108

00:08:14,870  -->  00:08:20,480
Now the synchronized method as we know use us bank account objects block that is the object on which

109

00:08:20,540  -->  00:08:22,330
the method has been invoked.

110

00:08:22,760  -->  00:08:29,120
Hollywood the deposit method is using a string object reference as the lock on that should not be done

111

00:08:29,120  -->  00:08:29,810
.

112

00:08:29,810  -->  00:08:31,960
So two different clocks are being used.

113

00:08:31,980  -->  00:08:33,720
You got the same variable.

114

00:08:34,010  -->  00:08:37,160
And so the effect of synchronization is lost.

115

00:08:37,170  -->  00:08:44,540
That is John an ostrich can be using synchronous stuff concurrently for instance lets say the bank account

116

00:08:44,570  -->  00:08:48,550
has only 25 bucks and John wants to withdraw a dollar seventy 75.

117

00:08:48,980  -->  00:08:55,790
So let's as you John request on it to transfer 75 bucks from her personal account to this joint account

118

00:08:56,540  -->  00:09:02,850
and that's all you got in a hurry on both axes of the system at around the same time and let's say on

119

00:09:02,870  -->  00:09:07,420
it AUSTRAC gets into the deposit met that and also into the synchronized block.

120

00:09:07,640  -->  00:09:14,090
But before the deposit is added sugar switches to Jon Stewart and Jon Stewart will execute make with

121

00:09:14,090  -->  00:09:21,770
donga method to completion and we find that there isn't enough balance and once Jon Stewart exits make

122

00:09:21,770  -->  00:09:27,340
that Dawn unattested that will come back into running state and their deposit.

123

00:09:27,350  -->  00:09:33,090
So John is still unable to withdraw the money just because the court was using different clocks.

124

00:09:33,140  -->  00:09:34,400
Maybe not a great example.

125

00:09:34,640  -->  00:09:37,110
But we shouldn't be doing this.

126

00:09:37,340  -->  00:09:43,390
Also normally an object's intrinsic clock is used to guard the shared mutable state.

127

00:09:43,880  -->  00:09:45,080
So that's about it.

128

00:09:45,320  -->  00:09:46,500
In less than 30 seconds.

129

00:09:46,670  -->  00:09:49,630
Let's also go ahead and make our make with Dolemite.

130

00:09:49,700  -->  00:09:54,140
Synchronized so that we can get rid of the race condition.

131

00:09:55,410  -->  00:10:01,160
OK here it is the bank account example and we know that the bank account object was not active.

132

00:10:01,280  -->  00:10:07,190
So let's just go ahead and make the make that automatic synchronized.

133

00:10:07,230  -->  00:10:08,230
Now we are good.

134

00:10:08,230  -->  00:10:13,600
I mean if we execute we can see that that is no longer the interleaving between the tracks.

135

00:10:13,610  -->  00:10:20,130
So John has withdrawn 75 bucks and when it dies trying to withdraw is not enough balance.

136

00:10:20,170  -->  00:10:21,110
OK.

137

00:10:21,110  -->  00:10:22,690
So that's synchronization.

138

00:10:22,820  -->  00:10:28,130
And in the previous season we also Lubet another classical idea generator which was generating unique

139

00:10:28,130  -->  00:10:37,790
IDs and it hard to get new ID and it could return the same ID on two different locations because the

140

00:10:37,790  -->  00:10:39,820
object was not turret's.

141

00:10:40,130  -->  00:10:43,950
So once again if we make unsynchronized it would work fine.

142

00:10:44,330  -->  00:10:46,940
So that's about it that's about synchronization.

143

00:10:47,300  -->  00:10:47,830
Thank you.

144

00:10:47,840  -->  00:10:48,710
I'm happy Cody