YouTube Video Transcript

[Music] hello friend this is rotating or watching see peanuts video series on C++ threading and this video is about uni clock in C++ threading and this is the same text for uni clock namespace STD uni clock and it is wrapper over mutex so it will own the mutex so this m1 is mutex and this lock is nothing but an object of uni clock will see all these things so what is the purpose of this unique lock and before this we saw log guard in previous video so if you don't know what is log guard I would suggest please go ahead and watch that video before watching this one so that you can link it better okay so first part is the class uni clock is a mutex ownership wrapper yes it will own the mutex whatever you will pass inside object I mean when you will create the object okay and what I mean by ownership and all I will explain all those things later so don't worry about that just understand that there is something or somewhere as TT mutex m1 then you can own this mutex by writing this as to be unique lock mutex and lock m1 and then you will handle this mutex m1 with this lock and this lock is nothing but a variable or object and it allows these many things so can have different locking strategies so when you are writing like this you have different different strategy so this is one strategy you don't have to write anything when you are creating this object another strategy could be as TD let's assume I have written unique log and then mutex and here some obj inside this you have to pass m1 and then comma and then you will pass the locking strategy and these are three locking strategy one is deferred log another one is try to lock and another one is adopt logging if let's suppose you are adding defer log here like this then in that case when you are constructing this object this line it will not try to lock this mutex it will say that I'll just own this mutex but I am NOT going to lock it or in other words it will wrap this mutex but it is not going to lock it okay the locking will happen in later point of time but not here but in this case because we have not given any deaf Erlich here in example so it will try to lock this mutex at this particular line only okay I'll show you all these things see this is the example and this is example number one I have two examples example number one is showing that I have not written any of the locking strategy then in that case it will automatically call the lock on the mutex M 1 ok and this M 1 is nothing but mutex here and another point is so we covered this one now another point is time constraint attempt at locking so you can actually attempt the locking using time constraint lock like try lock for and try lock until so I have given videos for these two you can go ahead and check out they are very simple it is nothing but you will do something like this m1 dot assuming this M where is nothing but this mutex m1 dot cry lock for here you'll give time and let suppose you have given two seconds there is a syntax to give the timing I am just giving you the overview then in case if this mutex is not free then it will read for two seconds the moment it asked for this log from that time to two seconds it will wait okay otherwise if you just simply m1 dot lock if you just simply lock it try to lock it and if this mutex is not free this is going to wait for infinite amount of time if it is taking infinite amount of time but in this case you can tell the timing and here also it is a similar but the syntax for time is little different for this until ok so these things are also possible with this unique lock so instead of m1 you will use if it is lock you will use LOC k and here - hello CJ not here leave it we are not talking about this one we are talking about this one so this is also possible lock dot Trilok for this much amount of time okay so time constraint locking is also possible with uni clock and third is recursive locking is also possible I have given the video for recursive locking if you don't know go ahead and watch that video transfer up the lock on ership yes you can actually move this particular lock somewhere else but you can only move you cannot copy because you cannot have to ownership of the same thing so suppose you have this mutex you cannot have two objects pointing to this same mutex okay obj to obj one so this is not possible okay so only move is possible you can move the ownership of this mutex from object 1 to object B then object 1 will no longer be the honor of this mutex okay so this is covered now condition variable this is a new topic I will be covering in next video or the next video of that and this is very good video or the topic it is used for notification purpose one thread t1 is running and once it is done with some job it can actually notify to this t2 which is actually waiting okay so t1 is doing some job and t1 is waiting for some particular new tags and once it is done it will notify to this t2 or number of threads can be there so it can notify to all that I am done and you you just come and try to get the mutex so there is a condition variable job I'll explain all these things in the coming videos so these things are possible with this unique lock and these are the locking strategies so defer lock there is nothing but do not acquire ownership of the mutex at the same time I have given this example in example number 2 so don't worry we'll see that and second is try to lock so if you use this strategy it will try to acquire the ownership of the matrix without blocking so if you are not able to lock the mutex it will not wait for that mutex okay it will go ahead and this one is assumed the calling thread is already has the ownership of the media it is like suppose you have already loved this mutex inside your thread let's suppose you have m1 dot lock okay so you have done this after this line you are creating your object like this and passing this m1 to that then this should not wait for this mutex because you have only logged it just after this I mean this particular line you just assume you have written this with comma here let's suppose you have lock and one comma this is strategy adopt lock so this makes sense right and assume that this whole thing from here to here is written here okay so you have already logged it I mean you have already logged this mutex and you have come to this lines means you own the mutex okay and then you want to create the wrapper of this mutex then it is possible you can just tell that I want to add the hop the lock which is already locked so this is how you use that a top lock now let's look at these examples and we will sum this up so as you can see that this is fairly simple program here and this is example number one forget about this example number two let me give some space here okay fine okay so we have two threads task will act as thread here and we will create two threads this t1 I am passing is a thread number and t2 is going as thread number so t1 or t2 any one of them can hold the lock here so let's suppose t1 have locked it then people will come here and will increment this buffer for loop for so loop for is coming from here so this 10 is assigned here and we will increment this buffer for 10 times and after this notice this we are not unlocking it because this unlocking is happening in the destructor of this unique lock okay so this destructor will be called because we have created this object in stack so destructor will automatically be called when the scope of this lock object will go off then in that case in that destructor it will unlock this mutex then once it is unload this thread too will try to lock it and will get the lock and will increment this buffer from 10 to 20 and let's see that execute this cd1 incremented this from 1 to 10 and that d2 started from 11 to 20 so any one of them can start first so it is not like even only we will start this first at T 2 will start second no T 2 can start first and T 1 can start later so you can notice that if you have not unlocked it t 2 would have never got this lock and only T 1 would have executed this and then what I'm saying is let's suppose if you are just simply using mutex just that's it just compile this and execute it see it is executed till T 1 and T 2 is still waiting see we are waiting and I'm sure we will wait till infinite and we will not get the lock I mean T 2 will not get the lock because T even only logged it forgot to unlock it so let's try to unlock that again even dot unlock so this is fine code let's kill this recompile it executed to see it is done ok so you have to unlock it but in our case we are not unlocking it it is doing the job automatically because this unlock is happening in the destructor of this one correct now let's move to the next example see we are using the locking strategy now and locking strategy is deaf or lock so it does not call the lock on the mutation because used deafer lock correct so this command says exactly what I said you before and as you have not logged this mutex here at this line you have to lock it later so why we do this actually what happens we are just saying that I am in this but I'm not locking it so you can have n number of code here and then you can lock it so this is the flexibility which is not available in log guard because log guard will immediately try to love this as I have given the comment here it is not needed as it will be unloaded in the destructor of the unique lock so this is fairly simple code let me just simply execute this one compiled successfully executed this one so this is also compiled and giving you the same output correct so I think I'm done here thanks for watching guys don't forget to hit the like button guys if you liked the video it will help me a lot and I'll see in the next videos bye bye