be689587-31aa-4495-9acc-ae3100d7e8aa.txt

ID: be689587-31aa-4495-9acc-ae3100d7e8aa
Title: Java Lectures
Category: Java
Lecturer: Alastair Donaldson
Date: 03/02/22
By the way, do you know where we can access these PowerPoint slides?
0:02
So the slides are all available on the materials website and they should all be up to date.
0:06
And hopefully the recording has now started. Sorry for those of you who are coming in on the recording.
0:12
Just the beginning, which was a recap and the talk about exclusion.
0:18
So what I want to do now is I want to talk about this example.
0:23
I think the lights of I'm going to. Because going to miss this.
0:27
OK, so. This is an example of mutual exclusion.
0:33
You can find this code in the concurrency repository that I linked to last time.
0:40
So you're linking the minute. But what I want to show you is a deadlocked bank.
0:45
So here's some code, and this is what it does.
0:51
So you've got. You've got two different accounts, so we both have accounts that Nick is me, Ali has got his account of money as well.
0:54
And the idea is that we're going to try and transfer some money to each other back and forth over and over again.
1:05
OK, so what are we going to do?
1:11
So we've got a whole bunch of transactions that we have. We're going to spit out what the actual balances are in accounts.
1:16
So we're very rich. We've got, I don't know, ten thousand pounds. OK.
1:22
And what we get to do is we're going to transfer 100 pounds back and forth across our house.
1:26
So there's this transfer, which cost Alex in your transfer from my accounts to Ali's account could be whatever amount we give it.
1:30
And we're going to start the Ali process. And similarly, we're going to say there's a new transfer which goes to NIC,
1:40
which the transfer from these accounts to Nick's account and there's amount and then we start the process as well.
1:46
So what we get to do is we're going to start a whole bunch of transactions going back and forth.
1:52
OK, so these are the transactions starting and what we need to do in order to make this thing actually work is we need to so.
1:56
As you recall from the last lecture, once we've done start, we've got these two threads that are now running,
2:04
so they're both actually executing in parallel, and this main thread needs to kind of wait for that process to come back and join.
2:08
So what we're going to do here is going to say for each transaction, we want to join back to make sure that everything is joining.
2:14
Another thing that I would say is notice the up here. I'm doing a thousand different answers, so I'm creating a thousand different threads.
2:22
Each one is to just under the transfer.
2:30
So if there's a problem in the currency, we're going to see it because there's going to be like thousands of threads all interacting with each other.
2:32
Try to consent this issue. So what we have here is final balance is going to be printed out and we're done.
2:38
So what's missing is what is the transfer because somebody told you what that is, so a transfer is a thread.
2:44
And you can kind of tell that already because we saw up here that we made a transfer and then we said to our start,
2:50
So whatever this thing is, it must be a thread because we're doing stuff on it.
2:57
And what exactly is the transfer? What we said?
3:01
It is a thread and it's got an account name from an account name to add some amount that it's transferring.
3:03
Those things are initialised in the ordinary way, so the variables just go straight in.
3:09
And then what we want is what are we going to do? We're going to look at the account from balance.
3:14
If it's greater than the amount that we won't be able to transfer, then what we do, we withdraw that amount from.
3:18
That's accounts. That means we're getting the gate value and then we deposit back into the second account and then
3:24
we print out the fact that there was transfer that happens and we continue what some accounts.
3:29
Well, an account is a thing that has an owner in the balance.
3:34
So the owner of the balance asset initially on the deposit, we increase the balance in the amounts and will withdraw.
3:37
We remove that amount. Otherwise, we've got a balance function that tells you how much you actually got in the account.
3:46
So that's that. And then we can also say to string, which gives to the owner of the account.
3:52
OK. So. That's quite a lot of coats to go through.
3:57
Hopefully, that makes sense. Do we have a questions about this before we start excusing it?
4:02
The questions in that case, what we're going to do now is I'm going to press play up here and this is going to execute this thing.
4:10
And given the name Deadlock Bank, we're hoping that it's going to have a deadlock.
4:16
And so what we have is we've got some initial balance and we're seeing a whole bunch of different transactions happening.
4:21
Everything is fine and now it's locked and it's not making any progress.
4:27
It must be that we have deadlock, so somebody is waiting for somebody else and we can debug this and go into it to see what's going on as well.
4:33
But essentially, all you need to know at this stage is something went wrong. It didn't work if I stopped the process and kill it.
4:41
That's the stop button here. I can relaunch the whole thing.
4:48
And what I'm hoping to see is that we're stopped in a different place.
4:52
So here we've only got one two three four five different transfers happened before it deadlocked.
4:56
And that's the nature of deadlock. Of course, we're talking about a series of transactions that happened.
5:01
A series of threads happened to leave,
5:05
and at some point something breaks and we can't tell when that's going to happen because we're not in charge of the scheduler.
5:07
Right. So we've seen that happen twice. So at this stage, it's nice, I think, to just get a sense of what debugging these programmes look like.
5:11
So I'll say I'll say two things about this.
5:21
One is. The debugging facilities in Saturday are really fantastic, and so they allow you to sort of step through the different processes pop by pop.
5:26
I'm going to go through that with you now so you can see how that's done. But the other thing I'll say is I never use it.
5:36
So. And the reason I never use it is because I'd like to just think about my programmes
5:44
first and then debugging by sifting through kind of tells you where the problem is,
5:49
but you should probably be aware of that to some degree. So I just find it not very useful.
5:54
It's more useful to have tests that have those tests fail.
5:58
And then you think, like, why did that test fail rather than kind of having to be taken by hand and followed through the programme until it says,
6:00
Oh, and this is what it felt like should probably work that out. But maybe that's just because I never play with massive, massive programmes.
6:08
And when you're debugging absolutely huge needle in a haystack and you've got like lots of other developers you work with,
6:14
you don't know whether code is broken because you don't know the whole code base.
6:20
So it's good to be able to learn how to use these tools anyway. So just because I don't use this doesn't mean you shouldn't know how to operate.
6:24
So let me have a look at how we this thing.
6:29
So debug button is here. We're going to get. And something is broken.
6:33
OK. And actually, we don't get to see where something is broken.
6:40
So what we need to do now is stick in some break points.
6:44
So what I want to show you is let's put some break points up here.
6:48
So stop deprivation. We did it again. And what you can see, hopefully.
6:53
I know it's really tiny. I don't know how to make this bigger.
6:58
But what you can see on the left hand side here is basically which thread are we actually looking at the moment?
7:03
I click on this thing. You can see that it says main at one in group main.
7:09
So that means that we're following the main thread when we step through this code.
7:14
We're going to see eventually we're going to hit the stop the stop condition here.
7:18
We're going to be able to see different threads popping up into the into this part of the code.
7:23
So if I. That's just get through specifics are just is like this thing here,
7:26
which basically follows the code through that is basically going through the code and having it executing different steps, I presume.
7:35
Are you familiar with debugging, by the way? Have you seen it in this course?
7:41
Yes. So this is the thing that will be new to you is going to be one which creates we're going to start this.
7:45
We're just about to start commands. So if I do start on this line, what happens is if I click here, we should see a thread.
7:53
So down here, there's a new thread that's been created. I click on that.
8:02
What we're seeing now is the state of the of that thread.
8:06
So if I press play through this thing, we're actually sifting through the the thread rather than stepping through the main, the main function.
8:10
So you can basically step through all the different threads individually to see what's going on.
8:19
So I'm step over this thing and I think, OK, I'm no longer able to press play.
8:23
Why would that be? So why is it that I can do all this stuff over? Is it because of hit deadlock?
8:31
It's not quite that. That's right.
8:44
So this threat is finished and it's done. So what we just saw was we went into May, we launched a threat and we stepped to that entire thread.
8:49
And then we and then we're finished. So there's nothing I have to see. I can go back to Maine, I can kick off another Fred and I can carry on.
8:56
OK, so we're just following the execution now. What we can also see, maybe it's a different programme,
9:01
but we'll we'll see is you can step through different threads and flick back and forth between them a step both through.
9:07
And at some point we might get into a situation where the debugger just no longer carries on going.
9:14
And that is because we've got these scheduled. And so there's nothing that you can do about that.
9:20
We're blocking for some reason. Right? And maybe that's because we're Brockman resource.
9:23
We're waiting for another flight to clear up before that carries on.
9:27
So just bear that in mind when you're doing debugging in this in this way, as you step through,
9:30
you'll get to a point where you're stuck, or you may get to a point where you're stuck. And that might be because you've acquired a lock.
9:35
We're trying to acquire a lock and you're waiting for somebody else to release that lock before you carry on.
9:39
OK. So. That's all I want to say about this example for now.
9:43
It's just like debugging is what you think it is. You just go through, you step through the instructions and things happen.
9:50
OK, let's see if I can get my slides back.
9:55
Oh, no, let's see if I really can. What are they? Oh, even better, they've completed.
10:01
OK. OK, so.
10:20
OK, we are here somewhere. So Section two, but they're not OK, so now what about locks?
10:31
Because locks of the way that you can avoid that lock? And I like to have some fun sometimes because life is all about the funds.
10:37
This is a picture of a lock because of locks, right? No, it's a picture of a cow.
10:45
Why is there because the cow has beautiful locks anyway, so you know, you have to try your about the place.
10:50
OK, so. Look, how do we use these things?
11:01
So the way that we can implement mutual exclusion is by having a lock.
11:06
A lock is a very special object. And it's not an object that allows you to say lock and then when you say lock.
11:11
Nobody else is allowed to to continue if they try to say lock,
11:20
as well as if you've got two processes and they both say lock and one of them is going to be allowed
11:25
to lock and the other one has to wait until that lock is unlocked and then they to have that up.
11:29
So the lock is the mechanism that we use to enforce a critical section, so it enforces that.
11:34
Nobody can enter this thing because only one person can have a lock at the time. So that's what this does.
11:39
And the key point is the last slide that says, of course, to lock and unlock are atomic.
11:46
They cannot be interrupted.
11:50
So there's nothing you can do to prevent somebody from locking is something that you can't sort of halfway through locking.
11:51
You can't have somebody else's schedule in this completely atomic.
11:56
This doesn't answer the question of how a lot is implemented, because it's like, well, they piggyback.
12:00
How did you stop that from happening? And there's the solution to that is it goes quite far and I don't really want to go into it, into it,
12:06
but it basically relies on the job of the JVM being implemented so that this is the property that it provides.
12:14
And that's based on ensuring that you have something called a semaphore or a monitor
12:20
that does the hard work of making sure that only one person can signal at once. We're not going to talk about that pretty much at all in this course.
12:25
So as far as you're concerned, you just need to know that locks work. How they work is is an operating system decision.
12:31
So there's some magic going on there, which we are just not going to go into. OK.
12:39
And so from the last lecture that this gets very complicated, very quickly, and I do want to to just yet.
12:42
But are there any questions about locks? I think they're really, really simple ideas. Yeah, please.
12:47
Yeah, that's a great was spotted.
12:58
There are locks called locks, which implement this in space, and they're basically the ones that everybody use to cover them.
13:00
So that's that's a really good point. Yeah. So you could implement your own thing as being a lock if you wanted to.
13:06
Oh, that means it's time for a break. So you get three minutes and then we'll carry.
13:12
For those of you listening online, that was my alarm going crazy. And.
13:27
You know, garbage collection is like what happens if one garbage trucks?
13:38
And then the other thread. Yeah. Well, good question.
13:44
Garbage collection and shows that it doesn't have to the objects unless there are no more pointing to that particular object,
13:49
which includes across all fronts. So how does it go the spectrum in a single press about like public garages?
13:56
So there's a counter on all objects and shows that that's something I try to do something.
14:02
Yeah, exactly. Yeah. I mean, it's actually I'm kind of cheating allowance of much, much more than not,
14:07
because what we call short garbage collections and full garbage collections,
14:13
it's the short ones I like to read and the collections which are all across the system.
14:19
Yeah, exactly. And so, yeah, it kind of it's more complicated than that.
14:25
And then I was wondering if I could mine and made it all the time. I was just wondering how much of programme specific stuff it's like.
14:31
Obviously, it does. I think, yeah, so all of the stuff about is that our problem just goes away.
14:42
Like, I don't know what my I my intelligence is not finding this okay.
14:52
There is a I'm a liberal to here and you need to add all of these as libraries to your to your projects if you just click on them, all of them.
15:00
Yeah. Can I just pretend? I'm not sure if you can do that, but I know you can.
15:08
You can certainly select them at his library at the bottom.
15:13
And then just want to go through, I think you can just do that. Hopefully that will take it off. All right, Jeff.
15:20
That race is far from over.
15:32
There was a question online. Wait, what did the D-Bergen say was the problem?
16:01
Oh, we didn't. We didn't uncover what the problem was.
16:07
We just showed that some you can debug step three things and eventually just just be careful to.
16:10
Some funds are being kicked out because I just finished doing this execution. Yes, OK, we've had our three minutes time to resume.
16:16
So where we got to is that locks are basically the way that we resolve the problem.
16:32
And so there are sometimes these things are called new taxes, which is just another piece of jargon that you probably ought to know about.
16:41
So let's move on to. So how do we actually share a lock?
16:48
So several threads can share a particular object.
16:54
So in this case, I'm going to call the object lock, but there might be more than one lock in the system.
16:57
That just makes things a bit more complicated. But roughly speaking, we're going to have a lock.
17:01
So if multiple threads call lock dot lock, then exactly one thread will acquire the lock uninterruptible.
17:06
It's atomic, you know it will happen. That's something that we can rely on, probably when some pretty close lock and run and return.
17:11
Sorry then to. Oh, yeah.
17:19
Tea is holding the log, so if he returns from the log construction, if the next instruction carries on, then it knows it's got a hold of the lock.
17:24
Nobody else has that lock, so you can think of that as being.
17:31
I've entered the critical section. Nobody else can be here. I'm the only one with the lock.
17:35
All of the threads will block on that call to lock until he releases the lock. So if another threat comes along and tries to lock that same lock,
17:39
then they're not going to proceed until his release is locked, so they're going to wait on that particular point.
17:45
And so, as you know, from the last lecture that puts them into that waiting state, they're no longer running.
17:50
And then at some point they're going to get a notification that wakes them up and says it's your turn to go back into running.
17:55
When they re-enter running, they're going to check again. Is that lock being used if it's not being used to acquire the lock,
18:01
if it is being used because maybe like six process, it's got woken up at the same time.
18:08
They all try to get the lock. Only one of them is allowed it. So once they've got that lock, everybody else is going to have to sleep again.
18:12
So there's a kind of wake everybody up and inescapable that again, this is where there's a new order between notify and notify all.
18:18
So Notify just notifies one process, whereas notify all wakes everybody up and then they have to rest for that.
18:26
Particular conditions have to be true, which may or may not succeed. OK.
18:31
So anyway, all of the threats will block collateral to lock, and then the lock is released by T by calling Unlock.
18:34
So it's a really simple solution to a difficult problem. So let's look at how we can do this.
18:42
So it really is as easy as you think about where the critical section is and then you put lock and
18:48
unlock around where the critical section is and nobody else can do that until you're finished.
18:54
So that basically solves the problem. Right? Wonderful.
18:58
So there is just another bit of information you probably ought to know about, which is good hygiene, especially in these days.
19:04
So what you need to be careful for is if you've got a lock, you're the only person that can unlock it.
19:14
What happens if you crash whilst you're holding on to lock?
19:21
Well, the rest of the programme is going to be waiting for your locks were released, but you've crashed and you'll never release it.
19:25
So that's the problem. So what happens is that people usually have locks and then you have a tri tri section.
19:30
So I try and block which says, here's what we're going to do the important stuff.
19:37
And then finally unlock the lock. And the reason we do that is that regardless of whether or not you crashed, you're in the critical section.
19:41
You know that the the JVM is good to execute, you're unlocking things and carry on.
19:48
So this is just basic, good, good manners for the rest of the system. Yeah, but.
19:53
Yeah, but. But when an exception has been thrown.
20:04
Yeah. So in Java, when we say crashed, generally an exception will be thrown.
20:10
One exception to that. Exceptions will be.
20:17
Suppose you have like an infinite loop. So while true is true and then boom, nobody's going to watch you spinning forever and making the CPU very hot.
20:23
I would consider that process crashed because what we call diverging, so it's no longer doing anything sensible.
20:31
And you could write code like that if you wanted to, and that worked through an exception.
20:38
But it also will stop the entire process like everybody else, from doing anything. It was questioned him.
20:42
Yeah, great question, so let's just go back a and then we'll get to that question. That's a good question.
20:56
So the question was what do locks prevent you from doing?
21:01
So what a lock prevents you from doing is entering a particular area of the code that somebody else
21:05
that prevents you from entering a critical section if anybody else is in that critical section?
21:13
So let's go back to the the overall problem that's happening here.
21:19
So we are let's focus on pretty pretty, reads the counter.
21:24
And then it says the state of the counter is one more than this count that it's got.
21:28
OK, so the problem with that is that you could have two different threads coming into this
21:34
thing reading the counter and then they they don't update the state of the world,
21:40
so they don't know what the value of the counter and they just overwrite it with whatever the values that they want.
21:46
So what you want people to do is you want people to say this block of code.
21:51
Only one person is allowed to write here at once. Only one person allowed to read and write at once.
21:54
This. Because they're reading the.
22:00
Oh, I see. I see a problem because they've got the county council at the top.
22:13
You want people to shift around. I think you're right and I think that's a real ordering of lines that's needed.
22:17
Yes. So I think I need to shift those lines to the critical section. It should include that read as well.
22:22
You're right. So yeah. Exactly, so things between lock and unlock, nobody else is allowed to do until you're finished.
22:26
And so to be ultra safe, we can move that lock up so that we can't even read from the outside before you continue.
22:40
And then nobody can read that before the person carries on. Does that make sense?
22:47
Great. Yeah. Oh, no. Yeah.
22:51
Yeah, but. Yeah.
23:02
OK, so I'll just repeat the question people like. So the question was how do you prevent race conditions on locks themselves?
23:06
I suppose, because you could have two processes racing through the lock. And maybe they do exactly the same time.
23:12
So they both apply the lock, right? OK? And the answer is magic.
23:17
So the answer is that's how the JVM was implemented. They made sure that this is something that cannot be done.
23:22
Only one of these is going to acquire it.
23:28
The so apart from the arts of magic, which is very unsatisfactory, I need to go into the answer semaphore and monitors,
23:30
which is all about operating systems and how they're implemented. But I don't want to go that.
23:38
But roughly speaking, somebody is in charge of what's going on and there is a way of flagging things up and says only one person is allowed to see,
23:42
this is lots to do this. And when things proceed,
23:49
so there is a there is a most granular operation and you'll see if you could do like the semaphore up and semaphore down operation.
23:53
Yes, it's like it's absolutely guaranteed it can, really. But that's kind of a long way of saying magic.
24:02
So. Yes, they do.
24:09
Yes, exactly. And it's actually quite an expensive operation.
24:15
So you want to avoid doing lots of lots and lots because it actually slows everything down.
24:18
You really have to be careful with them.
24:23
And so in a more advanced version of this course, I don't know if you do one electron, I think you will be doing one in two years.
24:24
You learn how to control smart phones, which are much more low level, and they allow you to do more fine grained things and lock through.
24:31
So the locks are quite stupid because all they do is that you lock and unlock them and
24:37
you can't sort of pass a lock around quite so easily where some phones can do different.
24:41
You can think of it as like that in your mind,
24:48
so you can think of it as a lock happens like requests for lots of in a queue and somebody gets picked and that gets processed.
24:50
I don't think that's what happens in reality. I think it's much worse than that in reality. Yeah.
24:58
So magic is my answer to that question. I think you had a question and then you saw how you create the.
25:02
Oh, yeah, yeah, sorry, that's not that pseudocode, yeah, we'll see it, we'll see.
25:11
It will be lock equals new lock and the network.
25:15
Yeah. Yes.
25:19
So the question was, is there a thing stopping a naughty thread from calling a lock when it's not as?
25:29
No, it can be unlocked so anybody can have an access to that lock is going to be able to do it.
25:37
So basically good manners prevents you from doing that. You should only really unlock after you've had a lock.
25:42
So that's what we kind of enjoyed, I could. Yeah, just critical pressure from pulling them out of proportion.
25:49
Oh yeah. So the question is of critical sections automatically detected or something for the programme to detect.
26:01
And the holy grail of concurrency is to be able to detect critical sections automatically.
26:07
We haven't got that yet, so we still the programme as detect these things.
26:11
There are tools that allow you to do some modelling of these things. So there are things to process process algebras,
26:16
which is where you model concurrency mathematically and then you can write equations that basically sort out how the process work.
26:23
And you can follow through these equations and eventually find out where the blocks could occur and identify critical sections.
26:30
So there are tools gold plated like that failure divergence models that allow you to do that stuff, but that's an advance because concurrency topic.
26:35
So for now, it's in your hands while we're here and help it like we're in this big mess because
26:43
we've got state and because we've got mutating states and the council can change.
26:50
And who knows when it changed by who? And that matters.
26:54
So wouldn't it be great if we had some kind of programming paradigm where there was no mutation and where all you had was like values that just were?
26:58
And then that means that there's no mutation, so there can't be any of this stuff.
27:05
And so everybody can just paralyse as much as they would, please. Wouldn't that be wonderful? Yeah.
27:09
So not everybody has the same problems.
27:14
So this is how any more questions about hygiene.
27:18
Yes, you do. Yes, and we're going to see that in about one slides time.
27:23
So, yes, I think so. So if if this doesn't answer your question again?
27:37
Yeah. Anyone else? OK, so I want to just talk about this first.
27:41
So let's do the counterexample again, but this time with locks, and so what we do is we have the run example and then we lock.
27:48
So this is just start beginning. So we've got the locked counter, which extends our concurrent counter.
27:58
And what we're going to do is we could create a new lock with a new re-entry lock, which is also in your question about how we do it properly.
28:03
And then we get to override the run methods because we are extending the concurrent counter.
28:11
We've got everything our parent has inside it's run method and we're going to just add something around that.
28:16
So this is like a way of just modifying that code a little bit. So what we provide it with?
28:20
Well, basically we do a locked up lock, which means I'm going to lock the lock.
28:25
Nobody's out to have it. And then we try SuperDart run. And I don't know if it's super, but basically that says,
28:28
please use my parents implementation of run when one parent means the thing that you're extending.
28:34
So that super dope run means go look at the definition of concurrent counters.
28:41
Run now, execute that. So that's the one that we've been using all along.
28:45
So now that executes this pass code, once you finished doing that, you know,
28:49
nobody else could have touched this code and you come back into the lock unlock and then everybody else is free to run that code as well.
28:53
So this basically resolves the problem that we had right at the beginning. Any questions about this?
29:00
Right. So.
29:07
Let's talk about restaurant locks. So as one of you noticed, at least at the top of this slide,
29:16
we've got this thing called lock rather than lock, because that's the implementation of this thing.
29:23
And so that could well be different implementations of locks that exist.
29:28
So you could imagine a non-related version of lock. Let's first inside what regimens.
29:33
So it means that if you lock a lock that you hold, you can carry on.
29:37
If somebody else tries to lock that lock, of course, they're going to block, right?
29:43
So if you've got a lock and so he tries to, they will block. But if you try to lock yourself, you don't lock yourself out of the house, right?
29:46
That's that's what the idea is here. So resentment means that it's OK if you keep on locking your own locks.
29:53
It's not like they accumulate. It's like you've already locked it that way. The car is locked and then you're probably not there yet.
29:58
One thing is your parents probably go back and forth, making sure that it actually is locked. Well, that's OK.
30:05
You can do that. Why would you not want this property?
30:09
Well, maybe it's expensive to make sure that this is actually happening.
30:14
Maybe you really ought to know whether you locked car or not, because then you'd have to walk back to the car and check has been locked, right?
30:16
So there are other implementations of locks that would be more efficient than the lock, but at least the entrant lock is safe in this way.
30:22
So that's that's the idea behind us. So generally speaking, just use your entrance.
30:29
How does not know which thread is locked?
30:37
The answer is magic, so locks are very, very special objects that have been implemented with these properties in mind.
30:40
So they they they cross threads, they're very magical.
30:49
All the threads get to see whether or not that lock is locked when they block on it.
30:53
So that's that really is the only answer I'm going to give you at this point.
30:57
I'm sorry, it's not very satisfactory, but it would answer that question properly.
31:00
I'd have to go deep into the deep, into the belly of the machine and show you some stuff and we're not going to go that OK synchronisation.
31:04
So another way of acquiring mutual exclusion is by synchronisation,
31:15
which basically says we can make sure that everybody is dancing at the same time and that everything will be working out right.
31:20
So rather than locks sync. And so there is this key word called Syncrude in Java,
31:27
which basically to all intensive purposes is like a lock around either a method or a block of code.
31:35
So this is not using lock, it's not using a special object.
31:42
It's using some special syntax in the language. So the word here is to synchronise word.
31:46
That's the new key word to learn. And what you can do is when you're declaring a method, you can put the words synchronised in front of that.
31:51
So saying synchronised to.
31:58
So that's that's going to be some something that some some would say, some object with some method with whatever parameters you want.
32:00
Basically means that that method cannot be executed by two threads at once.
32:12
So that is a very special method. Only one threads can go to it.
32:16
If two threats try to execute this thing, only one is going to be let through when that threat's finished with the synchronised method.
32:20
The other threads are allowed to go like this.
32:26
So you can think of it as being that somebody has very magically sprinkled locks before and after every synchronised method.
32:29
Yeah. So. That's.
32:36
And not waiting for it. So, yeah, you can when you call the synchronised method, you don't really know whether it's synchronised or not.
32:47
If it's synchronised and somebody else is called it before you basically who feel like you're waiting for a long time for that next retard.
32:54
And then what's this? Once you're allowed to, you enter, that method is not going. Yes, as far.
33:02
So if we go back to the counterexample that we had earlier on inside the run methods that it was like the increment counter function within function,
33:14
that was not a synchronous method before,
33:22
which meant that when two threats came along that both allowed to enter the body of that thing and do what they want.
33:24
All this does is it prevents them from doing what they want.
33:29
It means that when two people come at the same time, only one is going to be allowed through.
33:32
The other has to wait until that method is finished. And then and then the other one's not through.
33:35
So it's just magically sprinkling locks around is what you can think of as being.
33:40
But it's a it's a primitive in the language itself. Any more questions about this?
33:43
Yeah. If nobody else is blocking on this, then execute otherwise.
33:49
Oh, like, oh, like, oh yeah, I want to try this, but if if it's busy, I'm just going, I'll come back later.
34:02
Yeah, I see what you mean. No.
34:08
So that as far as you're concerned, you can't you can't inspect the whether something is being contested on one centralised, it's just invisible to.
34:10
I don't know. I think you could probably do something cheeky. I imagine there might be something going in space, but frankly, I don't know.
34:24
Tell us if you find out. OK, so let's synchronise methods.
34:31
Sometimes you'll find that synchronising an entire method is just a bit too much.
34:38
So imagine if you can enter some code,
34:43
you do a whole bunch of processing and then there's only one tiny illiquid sector critical section inside that method.
34:45
You don't want to have to lock the entire thing.
34:50
Everybody can do that non non-sensitive processing before they hit that special path, in which case you can put synchronised.
34:52
I put this here, so that synchronised on a particular object, maybe the object is the object that we're dealing with.
34:59
And then you can enter the critical section on that.
35:05
So the thing that I want to just highlight here is I use the word this that actually that could be synchronised on any particular object.
35:09
So Java has it so that every object is something that you can lock on using synchronised.
35:17
In other words, any reference you can make sure that you can basically lock on this thing so you can create any object as a lockable thing.
35:23
It's a bit of a strange idea.
35:31
You probably won't use it, but I'm just saying it so that you're aware that you can synchronise on a particular object before you carry something.
35:32
So very often the pattern is synchronised on this, which means I'm the only thing that's I'm surprising on this particular object.
35:39
And then we carry on. OK.
35:45
And I think. What I want to say is synchronised blocks and objects, so these things are all free entrance,
35:50
so you don't have to worry about calling yourselves if you have a method and synchronised and you call yourself that methods,
35:57
you've got some recursion. That's OK. You're allowed to and you'll be allowed through. You will have to wait for yourself to finish.
36:05
Similarly, if you had a synchronised block inside a loop so long as you're the one that's acquired that synchronised section,
36:10
you're allowed to carry on going through that loop. But I'm not.
36:17
Spend this.
36:26
OK, so your question was if you've got two different synchronised blocks inside inside a method and they're both synchronising on the same thing,
36:29
so you would say you go through, you hit the first synchronised. Then if nobody else has the resource, you're allowed to execute it.
36:35
Once you leave the synchronised block and another one, then you're just treated like everybody else.
36:42
So you're no longer special, but. There.
36:47
So two different methods. But. With the same this, so you will cause deadlock.
36:56
Yeah, so if if you kind of you or you can cause a lot depending on.
37:05
Yeah. So you just have to be careful with that. I thought I saw a question.
37:09
OK, so let's talk about how we would have counters using synchronised methods.
37:19
And so what we do here is synchronised method counts, implements runnable and what we do is the we have we have to change the signature of run.
37:23
So it's now synchronised so public synchronised void run. And then you're done.
37:33
That's everything that you need to do. And the other one that I want to talk about is the synchronised block.
37:37
So this is where we implement runnable and rather than synchronising the entire methods, so we don't have to do that,
37:44
we can actually just synchronise the part of the code that needs to be in the control section.
37:49
So that's the way you do it here. So really, there's just different tools for achieving the same thing.
37:53
OK. So each object to your question, is I doing some of this part?
37:58
Oh, you're on the boat. That's why I'll ask this question, then we'll have very early on when we have locks,
38:10
we basically said to the lock, please lock yourself and then unlock.
38:16
And so we were talking to particular lock in mind synchronised takes in a parameter which says,
38:20
which lock do you want to lock on or which object you want to lock on?
38:26
So you pass it in a reference to an object, and it makes that object turn into a lock that will be synchronised.
38:31
The reference that we're passing here is the reference this do you know what this is?
38:36
So this is the current object that's being created. So what you're doing is you're acquiring a lot on yourself.
38:42
So anybody else who wants to acquire an object, a lock on that is not going to proceed?
38:47
Hopefully that helps. OK. Three minute break.
38:54
But you know, more than that, until we can have a 10 minute break to 12 and then we carry on at that point and then.
38:59
Some of you need us. Our next question.
39:09
So it's good to see you.
39:27
I just don't know if you were writing this advice, but not until we get released on the subject of this blast of threats.
39:31
If it wasn't for this particular threat that we have to threats was not like the other one of the book that defies the law of the object of a lost.
39:58
Yes. You have a little bit of press and a lot of that stuff,
40:22
but what do you see for based on a lot of a lot of the stuff you just said and that helps us in office?
40:30
So again, the threads likes to interact with a lot of them, obviously, but we don't want to overlook that.
40:41
So the synchronisation happens at the local level like the threats to the opposite side.
40:59
Well, it makes life like it's hard to say.
41:08
So I think it's up to both of you to have either one of you ought to have some sort of arrangement with them.
41:18
So it's not quite one of those things.
41:47
As always, things like the synchronisation, a lot of people say it's irrelevant, all of which is feel without any consequence.
42:09
So I think we have things like that.
42:42
It's important to respect that.
43:03
I think that's right. I just thought it was to play area.
43:09
All right. All right.
43:22
Let's take a listen to what we have to say.
43:32
What does this say about, you know, Jeffrey, if you have a global?
43:57
I know people like on the other side of the road, but in their heart of hearts.
44:27
Yes, yes, I say to him before I go to church, I mean, this was it was, I think it was somewhere else.
44:43
As far as the communities I know, the names, the so sexy here.
44:59
Oh, right. Yeah, no,
45:07
I but I don't know what they to call this because they don't allow us to hear something
45:15
like this that might be compatible with something that's going on right now because
45:58
it's really it's just it's just trying policy that it must be able to get involved
46:18
that there is no reason to go back to the old enough time to just say these are.
47:07
But I cross the what to say, just how you prevent something like that.
47:45
I do watch this part of.
48:08
Does it make politics OK?
48:38
I think that time up. So we'll have another break in twenty five.
48:50
So I had lots of questions about synchronisation, which tells me that I didn't explain it well enough.
48:55
Or at least we need to explain again. So what I want to just say is the idea with synchronised.
49:02
The synchronised keyword is that we're synchronising on a particular object.
49:10
So if we're doing synchronised methods, so that means that nobody else can enter that method for that object.
49:15
But that's basically you've got two threads interacting on that particular object.
49:22
They cannot enter that method or in fact,
49:26
any other method that's been synchronised in that object without waiting for something to do that with anybody else to enter that.
49:29
So you can think of it as a synchronised method is you've got a particular object.
49:35
That's the resource that we're going to all fight for this because the database for this thing and
49:40
it's going to make sure that only one person is allowed to acquire the synchronised lock at the time.
49:44
The sexualised look can be method wide as we saw, and it can also be specific to a particular block if it's specific to block you,
49:49
tell it which object you want to use as your lock.
49:59
So it's almost like the synchronised method story, except you can say you can define which object it is.
50:03
It's not just this object all the time, it could be some other thing as well. So.
50:08
Remember that? In order for this to work,
50:14
you need to have several threads and they need to be trying to access some shared object and the fighting for access to that object.
50:18
So the reference to this makes sense because the objects all think it's the
50:27
same beats or the threads or think it's the same object they're fighting for, and it's going to decide which one of the threads gets to continue.
50:31
So that's roughly speaking how this works. Let's take two of the comments as well.
50:37
One is you could have lots of nested synchronised blocks where you're synchronising on different objects.
50:42
One of the way to say this is you could have nested locks so you can imagine
50:50
having like not the red door lock the blue door lock on the green door lock,
50:53
and once you unlocked everything you're allowed to go through. That's perfectly possible. You can have multiple locks, one inside the other,
50:57
and in the same way you can have synchronised blocks, one for the other, locking on different objects.
51:03
This is a very unusual thing to do. We probably won't ever need to do it at all.
51:08
But I just thought I'd throw out that as a this is possible. If you do this kind of crazy stuff like that, lock is going to be very,
51:12
very close by because things can go wrong when people acquire the locks in different orders.
51:19
So imagine you've got to do with like a blue or red door. And the only way to go through is if you do blue first, then red, right?
51:23
And then you're in. But if somebody else is allowed to do red, followed by blue and you get the blue door and they get the red door,
51:28
then you can be waiting for each other lock to be released before you continue to go an easy deadlock
51:35
here because we've got some ordering that can be tangled up in the way we acquire those locks.
51:39
So you need to be careful as a programmer if you do this sort of thing to make sure your locks all happening in the same order that everything is OK.
51:44
So just be careful that. And what else that I won't say, oh, the last thing I wanted to say was somebody asked about what,
51:49
why don't we just like, look everywhere, I suppose, was the way the question goes. So maybe you can give me an.
51:58
Why would we lock everything all the time? What's the problem with that? It's expensive in which way.
52:04
Yeah, why would that be expensive time wise? They.
52:13
But. Yeah.
52:22
The. Yeah, exactly. The whole purpose of this exercise is to gain some speed and performance because multiple things can happen at once.
52:32
If we lock everything, then you may still make a single threaded application where everyone gets their turn,
52:41
but nobody else can do any any execution at the same time. So this is just like a complicated, single threaded programme, right?
52:47
So you want to make sure that there's as few locks as possible so that everybody can do their work at the same time,
52:53
and you want to make sure you lock a small region as you can, right? And so that again, as much parallelism can happen as you as possible.
52:59
So these are just things to bear in mind. OK. Right deadlocks, I mean, dreadlocks, ha ha.
53:07
So there are some so-called common conditions which specify the necessary conditions for deadlock to occur.
53:21
There are four of them. Yeah. So there's so basically. Each of these has to hold true for that to be potential for deadlock.
53:30
If one of these things is missing, you don't have to worry about that knock at all.
53:38
OK, so what are they? Mutual exclusion. So there has to be some kind of a zone.
53:42
Great. That makes sense. Hold and wait. It must be possible for a threat to request one resource while holding another.
53:47
In other words, can you have hold of all that more?
53:54
Is there more than one block basically? So you're holding one lock and you're saying, Can I also have this lock?
53:59
That's something that's necessary. If there's only ever one lock in the system, then you're good to go.
54:03
There can't be any deadlock, but if there are two locks in the system and some process can demand both of those things.
54:09
Hmm. Maybe there's going to be an issue we don't know. No pre-emption.
54:14
So this means that resources cannot be forcibly taken off threads that hold them.
54:19
So the idea of pre-emption is you might have it so that if you've got a threat, it holds a lock.
54:24
It's doing its work and then that say it crashes, then maybe there's the magical angel that swoops in and goes,
54:29
Let me take that lock from you and things carry on. Right? That's not allowed.
54:36
That's pre-emption, OK? And that's why we have to have that defensive programming. Earlier on that said, inside a try block.
54:39
That's what you're going to put in the in the catch.
54:45
You put the unlock because there is no pre-emption in Java, no angels will come in and take the local objects for you.
54:47
Right. So we're definitely in a cramped world in Java, and the other one is circular.
54:53
Wait for two or more. That's not how you spell two or more.
54:59
Threads form a circle of chain where this one thread is waiting for the results of another.
55:03
So that means that you've got one threat is demanding his resource and his resource is asking that resource.
55:08
When the supply chain here in the demands, that's when you can have that lock happening.
55:13
So. A way to sort of put this positivity is if you can annihilate one of these conditions and your code, you know, that cannot be deadlock.
55:18
So do we want to annihilate mutual exclusion? Well, no, because we've seen that that's what leads to databases and we don't want that.
55:27
Do we want to annihilate, hold and wait? Well, sometimes it's useful to have more than one lock at once.
55:36
So, for instance, you maybe you want to be able to ensure that you've got access to the printer and the network before you send off a very important
55:41
document that nobody else will have to see something that I don't think it's useful to have more than one lock sometimes.
55:49
So hold and wait to something that we certainly want to be able to have as as an idea.
55:55
So no pre-emption. Maybe we implement a JVM that can swoop in and release our locks from objects.
56:01
But maybe that's just too open to abuse. Maybe then you can start writing programmes that basically still locks up the people
56:09
when it's still dangerous and then allows code to be executed by somebody else.
56:16
And that defeats the whole point of locks because the whole point was critical sections.
56:20
Let's programme safely. So again, we don't generally allow pre-emption or somebody else off.
56:24
Can you unlock a lock? And I said, Yes, you can. So actually, pre-emption is possible.
56:30
Just don't do it. So that's something that we can think of.
56:34
And then the last one is circular. Wait. So can you have processes that rely on each other?
56:38
And that's the one that we tend to attack to try and prevent that from happening in the first place.
56:43
So earlier on, when we saw the bank account example, I was waiting on Ali's bank and he was waiting on my bank for the transfer to happen.
56:47
And at some point we're waiting on each other and we're locked. And that's because there was no kind of you first mentality, so there was no ordering.
56:55
There was a cyclic reference between this thing. There was no ordering on who can do what at what point.
57:04
So we'll talk about that in just a minute. OK, so this is the code that we saw.
57:09
And I want to just go for a bit more carefully, so we've got a run command, we've got to synchronise,
57:18
so we're synchronising on objects here, so we're synchronising on account from and on accounts too.
57:23
So you can think of these as being separate locks. Right? And if they count from about, it's a big amount.
57:28
Then we withdraw from from account and then we deposit the to account.
57:35
So threads tea transfers to account one's account two and thread you transfer through account to just one.
57:39
OK. So why does this cause a problem? Because one of them can attach the account from lock and then the other one's weight,
57:45
and one of them catches both of those locks and the other one comes in and it can't proceed because the other one's got the lock.
57:52
And so things just go wrong. So that's the problem with the locking.
57:59
How do we resolve this? Well, if we have some way of ordering these these accounts, then we can basically break the deadlock.
58:04
So we have to decide somehow what the first account to lock is and what the second account lockers.
58:12
And if we can do that, then we know that we've ordered the locks.
58:19
The blue door always goes before the red door or whatever it is to some kind of
58:25
procedure that tells you what the safe passage through the different accounts is.
58:28
So here we can, for instance, look at the account owners, look at the identifiers and say, you know, lowest identifier goes first.
58:32
And that means that we've ordered our way through the locks. You can only open these things in order. And so everything just blocked out.
58:40
So this is the kind of the solution.
58:44
So dealing with the deadlock problem that we had for that bank account system and that, I hope, is that so yeah, you've got a question.
58:46
I heard on the previous slide. The pre-emption.
59:01
Oh, so so the problem here is that we've got two different threats and you.
59:14
And the account from the account, too, is going to change, the one of them is one is the from the other one account to is the problem.
59:20
I see. Oh, we there is no pre-emption because the way synchronised works is you can't synchronise on a particular thing.
59:39
So if we were to implement this with locks rather than synchronised, we would have like a cow from dot lock and about 2:00.
59:50
And somebody could print by magically doing an unlock and then letting things go through.
1:00:00
So you could be like, Oh, I'm waiting on this guy. It's locked. I can unlock it and carry on.
1:00:04
And that's not possible to synchronise because there's no mechanism for synchronising something.
1:00:09
Does that help? Yeah. The question yes, or is it's like Facebook.
1:00:15
Yeah, so account one gets Locke's first account,
1:00:23
so let's suppose that we're looking at T so t the count from his account one account to his account account to is account to.
1:00:27
And then with you the other way around. So he executes it gets a count, one locked and then it gets count.
1:00:38
Two locked. Sorry. I'm going to quickly, he Locke's account one.
1:00:46
It's got the lock you locks account to.
1:00:53
It's got the lock to try to get it out to lock.
1:00:56
It can't. The other ones got it. You try to get the first catalogue.
1:01:00
Got it. That's OK. But I can't. It.
1:01:05
Because because you has got accounts to. Let's try that again, so we've got account from an account to.
1:01:13
For tea from IS one and two to four you promised two and two is one.
1:01:24
So tea comes in, it can it can lock account from, which means it's got the lock.
1:01:31
One of the most effective. All I need to do to demonstrate to your problem is show you how if we if the schedule gets things wrong,
1:01:37
then they can't proceed because the other one has got a lot that they need, so they are happening at the same time.
1:01:48
Doesn't even exist.
1:01:56
Yes, exactly. Yeah, that's right. So it could be that T just goes through and everything just works and then you go through and everything just works.
1:02:00
And we saw that an example earlier on because we had some transfers were happening and suddenly it died.
1:02:07
And the reason it died was because he gets the account from locks.
1:02:11
It locks out one, then you locks account to then t want to try and lock out, too.
1:02:15
But it can't, and you try to look at one, but it can't.
1:02:21
And so they're both waiting for each other. And that's that's where the problem comes up.
1:02:25
Does that help? So. All of the are.
1:02:29
Yes, so long as the guarantee that the locks are acquired and released in the same order, then we're good to go.
1:02:39
So that's basically what the fourth cost condition tells you. This last condition says there are no there are no circular weights.
1:02:44
So the problem that we had of the reason that a problem that was because he was waiting you and you was waiting on T.
1:02:50
Or in other words, you can only get lock to before you have lock one and not one.
1:02:55
We have locked, too. Does that circularity? So if we reorder the locks for the account, one is always unlocked.
1:02:59
Always lock the four accounts, too. And we're never going to get into this problem.
1:03:05
And so that's basically what the resolution is.
1:03:10
So the way we break this deadlock is we have two different accounts here, and rather than quoting them the count from two.
1:03:14
There's also the first account and the second account. So we always lock the first account before we lock the second account.
1:03:24
That's not something we'll get to decide on.
1:03:30
The way we choose which ones they are is to do with the owner of the account, so we just order them in some way.
1:03:32
That means that the two in the from kind of just gets set to be the right order, regardless of who you are.
1:03:37
So you can always synchronise the first account set on the second account and you're
1:03:44
good to go because we've made sure that the order of the box is always correct. I think this is the kind of intricate and difficult example that.
1:03:47
We could just sit here and try to do it live. And I suspect nobody would understand anything.
1:03:57
I think it's the kind of thing you need to sit down in a quiet corner and work out for yourself what's going to happen?
1:04:02
But I I think my role here is to kind of point out the problems, too, that you can go down and think about.
1:04:07
So hopefully this is helping. OK.
1:04:12
Exercise is not a bit time left. We're sort of ahead of time, so I think we're just going to look at this exercise in a bit of detail.
1:04:21
I've got a couple of other exercises to just point out as things that I'd like to try at home.
1:04:33
They're not things that you need to do. You could just not do them if you want to.
1:04:37
But the things that you'll learn from, so it would be beneficial if you did.
1:04:41
But I thought it'd be nice to just look at this pie calculator.
1:04:45
I did first get a sense of what the problem is and how to resolve it and see what this has to do with concurrency.
1:04:48
And then I will just talk about the other two exercises that are flagged up.
1:04:54
So if you're following in the notes line as the word frequency problem and this is an explosive philosopher's problem is it's kind of like classic.
1:04:58
So these three actually are classic problems that any computer scientist is worth their salt knows about, right?
1:05:05
So how would you generate a pie? Calculator is the first one.
1:05:12
So let's go through that. We'll actually see this next year when I teach you the advanced algorithms course will solve this problem in high school,
1:05:16
and we know there would be like almost nothing but today pain, right?
1:05:23
So so the approximate value of PI can be calculated by observing that payoff squared is
1:05:28
the area of a circle and when our equals one circle is in a square of sides like two,
1:05:39
so we're going to draw on the board just a big square.
1:05:44
And the best circle, like a minute. And so let's just imagine this circle with just one.
1:05:50
So then that means that this is square with sides like to. OK, now the idea is this what's the area of the circle?
1:05:57
Well, it's all squared and orange one. So the area of the circle is PI.
1:06:08
What's the area of the square? It's full, it's a two by two square, so it's full.
1:06:14
OK, so. Now, let's just imagine that I start throwing dots on the board randomly.
1:06:20
So I'll do OK.
1:06:29
And we do this. I don't know, ten thousand times I might stop. Never. Right.
1:06:35
So as I keep doing this, what proportion of crosses will land inside the circle?
1:06:39
Pi over four, is that one convinced of that?
1:06:49
Yeah, because you've got like every four five of them, supply food is going to be the fraction of things that are inside the circle.
1:06:52
OK, so we can exploit this to approximate pie.
1:06:59
The more dots that I throw on the board, the closer I'm going to get the pie as the proportions of dots inside the circle, just outside the circle.
1:07:02
If I just throw one there and it hits the circle, then what's the proportion of things that hit the hit the circle?
1:07:10
Will this one? So that's four, which means the approximate pie with the number four.
1:07:18
That's not very accurate. But there's a kind of one of four tells us what we get right?
1:07:22
I just there's a pie chart, so that's what we have one in pie over four dots.
1:07:27
So anyway, so that's kind of the game that we play here.
1:07:32
Now, rather than randomly making values between zero and two and zero into and sort of hitting on this space,
1:07:38
we can be a little bit smarter than this. We can just focus on this quadrant here, which has.
1:07:46
Values that say from zero to one.
1:07:52
And if we just generate X and Y coordinates between zero one that hit this, then the proportion of bodies that hit here is what?
1:07:55
So what proportion of the bodies hit the circle? Yep.
1:08:06
It's still the same, it's not it's not magically pie anymore, it's still quite full, right, that hasn't changed.
1:08:12
So whatever the proportion is, the things inside here, it's still going to be pie by fall,
1:08:17
which means that if we were to just count the number of hits and divide that by the overall his promises,
1:08:22
then we multiply that by four and we should get something that looks like pie. Yeah.
1:08:28
So we can do this using an algorithm that just does it like ten thousand times and gets a result.
1:08:32
But we're doing ten thousand times the same thing. So wouldn't it be nice if we could just divide that across several processes in each one of them?
1:08:38
Because it would have some of the number of times where, like, let's do fifty thousand times and have five processes is doing it ten thousand times.
1:08:46
So that would make it go five times faster than before. Right. What's the problem with this?
1:08:52
Well, we need to be able to count accurately and communicate that count between us feel to say, OK,
1:08:56
we're not we're not accidentally overwriting each other's count of how many hits and misses there are,
1:09:03
which means that we need the concurrent counter example that we've been talking about. Wow.
1:09:07
So let's look at the code that does this and then let's see if it breaks and see what happens.
1:09:11
Does that make sense? Does anybody want to ask about the general idea first?
1:09:17
This is oh, by the way, and for you, for your memories.
1:09:23
This is called a Monte Carlo algorithm, so this is because it's over time gets you a value that's kind of like closer and closer to the truth.
1:09:27
So there are other algorithmic Las Vegas algorithms, which sometimes which sometimes give you a false answer, but usually don't.
1:09:36
So these are the kind of two extremes of randomised algorithms.
1:09:44
So one of them is like as as you throw more randomness at it,
1:09:49
it gives you it takes longer and longer and longer, but you're getting more and more accurate results.
1:09:53
And the other one is as you throw more random audit, the probability that it gives you a correct result is higher.
1:09:58
But sometimes it just tells you something is wrong and you have to decide whether you're happy with that role.
1:10:04
So we're not going to get into that into any detail here.
1:10:09
But in some advanced algorithms, we kind of use these ideas to make things much faster because you like,
1:10:12
well, with some probability, it's the wrong answer. But I don't care. I'm happy with that, right?
1:10:16
Go, figure. OK, so it's not my pacemaker, I don't mind.
1:10:20
So what I want to look at here is to turn the lights out.
1:10:26
It's like that the students we turn the lights off, you fall asleep pretty quickly.
1:10:37
So. Here is the code for it, and I'm just going to basically talk you through it and then we'll execute it and then we'll call it a day.
1:10:43
So what we're doing here is we're creating different concurrent cancers.
1:10:52
So these are the counts that we can play with all along. We've got two of them.
1:10:57
We've got some number of samples. It's a million. We've got five threads and we're going to create havoc.
1:11:01
OK, so what do we do? We've got a threat list or threat of right with five threads in it.
1:11:07
And then what are we going to do here? OK, so this is something interesting. I've not done this before.
1:11:13
We are going to. Set will be threads to a new thread with a mock integrator, whatever that is,
1:11:17
integrator is the multicolour integrators, the thing that we're trying to implement.
1:11:27
OK, so it's just a thread that's going to do something with a number of hits, no misses, number of samples and a particular lock that is knocking on.
1:11:31
We'll see the code later once we've created our array and we set them all to be things that will do these Monte Carlo type things,
1:11:38
we actually need to go ahead and start them. So that's what this line does.
1:11:45
Now the threads are all live, they're all processing and they're doing their work.
1:11:50
We have put this in a stream notice, so it's erased upstream threads for each do this thing.
1:11:55
So we're using the threads, right? We're going to go through every element in threads, right?
1:12:01
So that means all the threads and for each of those, we're going to get them to get started.
1:12:05
So this is like how to programme nicely in Java without having folks everywhere.
1:12:10
So once we've done that, we know everybody started what we need to make sure we need to make sure that everybody
1:12:14
joins because otherwise the main thread won't know when the work is finished.
1:12:20
So we go through each of the threads we're going to try and join.
1:12:24
That means we're joined together. We're doing this defensively, which means that if something goes wrong within the stack trace, OK?
1:12:29
Again, you sort of don't really need this. Try this, try catch.
1:12:37
It will still work. But when things go wrong, there will be no recovery from it.
1:12:40
And I'm trying to get you into good habits, even though that's not really necessary in this example.
1:12:44
OK, so that's what is going on here and what do we want to do?
1:12:48
So once we've hit this line, everybody gets to join.
1:12:54
So once we finish this,
1:12:59
that means that we've finished doing the stream of threads and everybody has joined because we finished doing joint on everyone.
1:13:01
Right? So at this point, the work has been done. The threads are finished.
1:13:08
I'll give you a break in just a minute. And what we're going to do is going to find what the pie is.
1:13:14
So the plasma is four times the number of hits get count over the number of hits, plus the number misses.
1:13:19
Which is basically the thing that we just did on the board and then what do we do,
1:13:26
what we we don't have a whole bunch of information, so let's have a three minute break and then we will resume.
1:13:30
What's that up to? Yes.
1:13:47
Yeah, it's like always, does it just like lock everything in this object or it's anything else that's synchronised on that subject?
1:13:51
We'll have to wait. If you're inside that area, what took you?
1:14:01
So it's like I said everything else. We'll have to wait on that surprise before they can proceed.
1:14:06
So you can think of it as like we've created a lot of it's called this lock theorising on the
1:14:13
object and anybody else that wants to access that lock has to wait till you're finished with it.
1:14:18
So this section of the code on this object? Yeah, because you can have this object being shared across different methods with different blocks,
1:14:23
any any of those things that try to access that object and have to just wait until
1:14:30
the finish is a dot object or that specific section of code on that object.
1:14:34
It's just that it's not objects, so it's not technically feasible, Richard.
1:14:39
All kind of more of synchronisation because like, yes, if it's just doing a method, it's just.
1:14:45
Oh yeah. So so the thing is that that's why you need to pick up which locks you get wet.
1:14:51
So sometimes you might have a lock for a particular group of methods that dangerous together
1:14:56
and another lock for a different group so that these things can happen concurrently.
1:15:02
Well, I thought it was like using block synchronisation was like you can only synchronised this small section of code,
1:15:05
but I like now, you're kind of like this, this object, which is a larger scope.
1:15:13
That's true.
1:15:17
Remember that the object that you're locking on is a future site so you can have different locks lock in different parts of that same surface.
1:15:17
Because the synchronised lock takes in an object name, you can you can decide to have different synchronisation points or different.
1:15:26
So it's not everybody has to be on that side. So you could have like five objects that this one is part two three.
1:15:34
So long as there's no exclusion property between this, it's OK to do, and I'm excited about the visual.
1:15:43
That's what we here, because on to orders, then it's not.
1:16:08
It's not quite understand yet, but this is going to be one of the great things.
1:16:28
Yes, you are.
1:17:02
OK, let's get cracking. I think we're going to be able to go home early today.
1:17:12
Right. So let's carry on through this. Is that dark enough?
1:17:20
Well, there we go. Definitely not enough now. What was I saying?
1:17:31
I was talking about this programme. I think we just went through. We talked about what Maine is doing, so that should be relatively straightforward.
1:17:34
And we're going to print out all the different stats that we want. Let's look at what the integrator does.
1:17:41
So. What does it have?
1:17:47
It has a final no hits.
1:17:51
So these are a it has a concurrent counter. It's a numbness.
1:17:55
It has some randomness. We've got some number of samples and it's got a particular lock that we're dealing with.
1:18:01
And then what are we going to do so when we make one of these things we set will be things to be what they need to be.
1:18:07
This takes in a random seed, you know, random number generation.
1:18:13
Yeah, good. And what we got to do now is we run.
1:18:17
So is this so OK?
1:18:21
So what we're going to do is we're going to go through each of the number of samples to remember this is happening per thread.
1:18:27
So there are five threads running this code. So they're going to go from zero to the number of samples.
1:18:33
And for each of these things, we're going to generate random X, generate a random Y and we say is hit if x squared plus y squared is equal to one.
1:18:38
So that's basically if you look on the diagram here, we're generating between zero and one here, zero one here.
1:18:48
We're looking at this thing here.
1:18:53
We just check and see, is it inside the circle because we know the rule about the hypotenuse and that kind of what Pythagoras is, right?
1:18:55
So if it's hit, then that means that we're inside the circle, which think we ought to do this.
1:19:01
We knock a log and we're going to increment the number of hits and then we unlock.
1:19:09
So that's good. Otherwise we knock a log. Do the maths and then we unlock.
1:19:14
And what's wrong with this code? Look, hygiene, yes, so this is not hygienic, right?
1:19:20
So it would be nice if we had hygiene. Anyway, the Cancun counter is just the fact that we know.
1:19:30
OK, so let's execute the code. And.
1:19:36
Three point one four two three nine four four. Close enough.
1:19:48
Right. And as you try this thing, you're going to get close and close by like those peak geophysicist friends about what their value is now.
1:19:52
Let me just if we could get what just happened. Are you happy with the food?
1:20:00
About 30 percent of. So your question was we're looking at unlocking.
1:20:07
I think you're asking about this is your question, you know?
1:20:18
I'll try to get to this one, though.
1:20:24
We could yes, we could have single look outside the if and then unlock the outside, but does anybody want to tell me why?
1:20:28
Why, that's a bad idea.
1:20:36
So we could have one, OK, so we don't need to have one on each of these things, we could have a single look around the whole, if not.
1:20:40
So that again. I don't think that was the suggestion.
1:20:50
I think the suggestion was just to clarify that we move, we put a lock up here because.
1:20:54
So I think let me just make sure that I've understood the code,
1:21:03
I'm going to forget about hygiene because I can oh, I don't mean to do this, but what to do here?
1:21:05
Something like this? All right.
1:21:12
So I think this is the code that you had in mind, right? Yes.
1:21:16
Yes, exactly. So let's just imagine this idea, that's not the problem.
1:21:24
So the problem here is we're going to look at the beginning and we're going to look at the end and say we're looking none hit and miss.
1:21:31
Right? But that's a bit of a shame because suppose you've got like 20 goes in a row.
1:21:38
It's a hit for one thread and for the other thread, it's like the 20 misses in a row.
1:21:43
Those two things could happen at the same time. But with this code, they're both going to lock one of those can lock before they proceed.
1:21:49
So there's a kind of a wasted opportunity parallelism here. You've got a question.
1:21:56
Indeed. Yes. So good. So we actually need multiple locks for the whole truth.
1:22:07
So we should start locking on something else. What should we lock on?
1:22:11
Yes, that's right. So you would like to have a lock on some hits and lock on the miss?
1:22:18
Yes. Let's do a synchronised block instead. This is great so we can have synchronised around them, hits a synchronised around them, hit.
1:22:26
And then that means that anybody that wants to hit or miss has to make sure that nobody else can do that at that point.
1:22:33
That would definitely improvements the code. Yep. Yes, that would be a much better way of writing this code, indeed.
1:22:39
But then this whole exercise would be. Yeah, yeah. Yes, absolutely.
1:22:53
I mean, we could just do this in another language, and we wouldn't have worry about this too. Yes.
1:22:57
But I'm really glad to hear that you've managed to basically resolve all of the issues that I have with this code.
1:23:05
So the the question started with why don't we have a single lock on the whole thing?
1:23:11
It's sort of equivalent. Right? And then why do we have more granular locks?
1:23:16
Great. How do we do that with six blocks almost to the object finger? Guys, I've learnt something.
1:23:21
Well done. So that I think is all I wanted to show you with this thing.
1:23:25
I did want to do something naughty as well, because what's the best?
1:23:30
We would pass in them, hit and miss because we're looking on that particular thing.
1:23:38
Yeah, let's do something naughty. I want to make sure that this works for now as well.
1:23:43
Let's try debugging it. Oh, oh, did I?
1:23:57
Oh, what do I do? It's a costume change, I guess, sir.
1:24:09
Where did I go wrong? Oh, yes, thank you.
1:24:15
So that means to go out here, that's just like this thing.
1:24:20
Yes, OK, so that's approximately five. I don't know what this is saying. So this is working still.
1:24:29
What was an autistic child through? Oh yeah. This is like.
1:24:37
Let's do this best. What's going to happen now when I press play?
1:24:45
So I believe the four times and. What will happen?
1:24:50
Yes. So went so zero, because the whole Java programme is so let's just play and see what happens.
1:25:01
So some of you might be thinking what just happened? The answer is our approximation of PI is zero.
1:25:12
Why? So let's just have a look.
1:25:21
The numbers returned were we did to five million executions of this thing and three million nine hundred thousand of them were inside the circle.
1:25:27
And so some for some reason we got to zero after this thing. Why?
1:25:37
I think it was to. Yeah.
1:25:41
Yeah, so there's something really cheeky going on here, and I like I like to catches up with these sorts of things.
1:25:58
These are like horrible code interview questions. OK, so if we look at what just happened, get count is an integer returns an integer,
1:26:03
and so the number hits divided by the number, so the name hits divided by the look.
1:26:12
It's just the myth is going to be an integer divided by an integer, and the result has to be an integer.
1:26:17
So if we do that number, we're going to get some fractional outputs.
1:26:23
That fraction is less than PI. Over four PI is three point something.
1:26:29
So Pi over four is nought point something.
1:26:34
But because we only do integer division, it has to be zero.
1:26:39
So the result is zero. Huh? OK.
1:26:43
So how would I fix that, suppose I did one point.
1:26:47
Zero times. I don't know what this is doing. Don't ask me. Cancel, right?
1:26:52
So if I do 1.0 times, is this going to return?
1:26:58
Some said the answer, and some said probably so. Bye bye.
1:27:06
Yeah. OK. Let's have a look.
1:27:11
We got bye bye for OK. So why did that work?
1:27:18
Why does one point zero times work? Someone at the back there.
1:27:22
Exactly. So because we're doing 1.0 times something.
1:27:37
Dropping those, are you doing a float multiplied by a number?
1:27:42
So I'm going to turn that number into float, whatever that is.
1:27:47
So it turns the account into float. And then it goes, Oh, I'm dividing a float by an integer, which means you probably want to float back.
1:27:50
So it turns the whole thing into float. And so the whole thing works out, OK? So yeah, that was kind of just the lesson in.
1:27:57
Pipes really matter, and when you let go of Typekit type safety.
1:28:07
Very unexpected things happen, right?
1:28:12
So here we had the zero rating out and you didn't really expect that one because we're doing this implicit cost from an integer into a double.
1:28:14
Only after the competition is finished. So when things went wrong, we were getting an integer which was zero, putting into a double.
1:28:23
It would have been nice if I had control over exactly what that mechanism was,
1:28:30
but I guess I did because I could have costed it automatically if I wanted to.
1:28:34
Wouldn't it be nice if I was told, by the way, you're trying to turn in a strange double, maybe something's gone wrong here?
1:28:38
That would be good. Yep. No, I mean, you're speaking to the wrong person if you ask the Java programme.
1:28:44
Yeah, this is like you speaking to me.
1:28:57
And I think it's really good if if we think about type safety and we take it seriously, it's like a tool that we can use.
1:29:01
So in my mind, casting like this is just a bit cheeky and it leads to code that's slightly brittle.
1:29:08
So the thing at fault here is that we are taking an integer and we're just letting the system cast it through.
1:29:15
Maybe we should be in control of that process. But hey, welcome to Java.
1:29:22
Anyone else on individual? But what your sorry.
1:29:26
If you. Like this? Oh, you want this like this?
1:29:37
OK, that's that's a that's what's going to happen. Zero, the white.
1:29:49
I can't hear too many voices. I'm sorry. Why? Yes.
1:30:05
So without the parentheses, what was happening was the doing one times the name hits and that cost of that to double.
1:30:14
And then we had a double divided by an integer, which cost of that into a double.
1:30:21
Right?
1:30:25
So that's why that works when you do it this way round the division is an integer division that gets you to zero and then you're doing zero times one,
1:30:25
and that's going to go. It's it's going to do if constant to double, but it's already zero.
1:30:32
So just be careful. This is like a complete minefield. OK.
1:30:39
That's enough playing unless somebody else wants to modify some code.
1:30:43
This example is online in the repository you can play with it in your own time, have a look of electrons.
1:30:49
See what happens?
1:30:55
And I just want to finish off by talking about the two other problems that we can do as far as these are for you to do in your own time.
1:30:57
But they're quite fun. So Shakespeare wrote a lot. A lot.
1:31:04
And so the idea is that we're going to go through his texts and we need to
1:31:09
we're going to build a map that tells you how many times each word was used. And so we want to do that quite quickly.
1:31:14
So how are we going to do that? We're going to have several threads going, going to go through the text in some way.
1:31:18
And they're going to start counting some words. And so you want to make sure that they tell you when a particular word has been found or not.
1:31:22
So that's the idea with this one. There are many, many, many ways of solving this problem.
1:31:28
Some using some nice algorithmic data structures that we haven't been teaching yet.
1:31:33
So you could just think about doing it the brute force way for now. But there are smart solutions to this problem as well.
1:31:37
So have some fun try to make it concurrent. Try to see if you can actually get these facts to work.
1:31:43
Working all at the same time and funny facts, frequencies of words in a human language tends to follow Zip's distribution.
1:31:48
So let's see if you can get distribution out of Shakespeare.
1:31:55
So that's it just so happens that this is a property of languages. So hopefully that will make sense.
1:31:59
It's quite a straightforward exercise. I think it's just good practise for you to have a have a go.
1:32:06
There are some and code you can find in the repository as well, so you can have a look that gets started.
1:32:11
And another exercise for you to think about is the dining philosophy philosopher's problem.
1:32:16
So everyone knows about the dining process problem. He's done some concurrency.
1:32:20
The idea is that you've got some philosophers. There are variations of this involving forks rather than chopsticks.
1:32:24
But basically, they're sitting in a circular table.
1:32:32
And the thing with philosophers is that they need to eat spaghetti or the noodles with either two chopsticks or two forks.
1:32:34
They just won't eat otherwise. Right? And so the problem is that what they do is they what they sometimes they eat and sometimes they think,
1:32:42
OK, and when they're thinking they're not eating. That would be rude.
1:32:52
So what they what they do is when they eat, they need to pick up their forks or their chopsticks.
1:32:57
Then they use them and then they can carry on.
1:33:02
What if there were like an old number of philosophers that it's possible that somebody picks up the two,
1:33:05
by the way, they'd say they don't care about hygiene at all,
1:33:11
so they're very happy to share their chopsticks and therefore they've got one between them and somebody might pick up both chopsticks.
1:33:14
And then the other person wants to do that with with that too. And then we've got deadlock.
1:33:21
So this is like a deadlock problem and the way to resolve it is you.
1:33:25
No, the philosophers and philosophers zero eight.
1:33:28
And then then when they finished, no work to go until then.
1:33:32
That's how you resolve this problem. So what you should try to do with this problem is model it.
1:33:36
See if you can have an output that says, you know, philosopher and is eating and make sure that they they can only eat.
1:33:41
They have to pick up their forks so, you know, prosper and picks up left fork picks up.
1:33:48
Right fork starts eating. You want that to happen for all of them. And then what you want to do is observe if you do it badly,
1:33:52
you're going to get that look and then try to fix that deadlock by making sure there's some kind of ordering between those philosophers.
1:33:59
Again, look at the code that's there. It should be interesting and have a look around at the problem.
1:34:04
There are loads of solutions online. It's just worth getting stuck into this to get a sense of what's going on with that.
1:34:08
Good luck. See you in last. Think next week is Ali?
1:34:15
And then for a week and a half and then I'm back on again, so you won't see me until later.
1:34:19
But good luck with this.
1:34:24