Semaphore in Java Concurrency

[@naruhitoabiku9451]

those were the clearest 9 minutes of my whole day

[@AshirwadPradhan007]

No amount of appreciation is adequate. The way you relate textual, monotonous OS concepts with real life scenarios is amazing. Keep up the good work.!!!

[@aditchauhan876]

Your channel is beyond any praise .

[@BharCode09]

Thanking you for these videos is different, but Oracle's JDK team should pay you. YOU are THE ONE who has put these concepts into such clear and neat explanation allowing people to use it the way it's supposed to be. Java docs make sense only after going through your videos! I know the effort it took me 5 years ago, to understand Java5 concurrency concepts. My brain used to bleed through my nose, ears :P every time used to read, java doc and different articles to get the grip of these.

[@pramodkumar-fo5sy]

This channel nailed it really, your easy way of teaching make complex topic like cake walk.

[@therealjordiano]

The quality of explanation here is very high, amazing stuff, thanks so much

[@alokrm]

number of likes deserve to be same as number of views. you are a champ. love to watch your videos and learnt something new each time I watched your videos. please don't stop uploading videos.

[@npantic]

I like your way to simplify the problem and use non-ambiguous terminology and examples to explain it in the simplest possible way. It reduces the need for lots of cognitive effort. A lot of people teaching online completely fail at this point.

[@keflat23]

after 3 days of searching content finally i found you! thanks alot ! super clear explaination and great tips

[@SunnyKumar-ud9gp]

In love with the content..please resume the video making. It will help a lot of people!

[@vadirajjahagirdar9342]

One of the best explanation on YT, right now. Thanks bro

[@ArchitGupta0x2B]

This channel is a gem in terms of practically explaining java concurrency principles. Thanks ^ thanks. Nowhere have i come across such lucid explaination of these things.. i have learned most of these hard way.

[@ArchitGupta0x2B]

One question wrt to this video. Can we acquire semaphore on one thread and release it in another. I know this is required for locks.. but what in case of semaphores?

[@DefogTech]

Yes, you can.. but i don't know of any use cases where we would need that. Semaphore is mainly for coordinating how many parallel threads can do some tasks

[@spaarks84]

This made me actually understand some concepts in Golang better. You are awesome.

[@sagarshekhar6296]

Before watching this video,to understand semaphore precisely was a nightmare for me... Excellent explanation....

[@vijiithaas2177]

Such an awesome video, why there are no videos off late? I started understanding concurrency only because of you!

[@balogunoluwatobijohn154]

This is really an awesome explanation. Thank you very much!

[@roman_mf]

Great content! Definitely going to watch whole concurrency playlist, having watched a couple of videos from it I'm sure it will not disappoint.

[@ahtashamulhassan6260]

Love your teaching style. Make very easy and understandable

[@subramanyakrishnamurthy8352]

You make it all look so simple! You're the best.

[@analogylibrary]

This is the only place I got to understand such complicated things in bread and butter manner.

[@edeepakjain]

Excellent.. simplicity at its best 👌 God bless you 👍

[@kevinspacey6090]

You're very good at explaining things.

[@lanatimmo3686]

Thank you so much! Such a good and clear explanation, I finally understood this topic :D

[@Abdullahkhan-ks2py]

Nice explanation with an even better example. Thanks

[@sandeeprm]

Nice video. Just to add...It is best practice to use try-catch for acquire/ release

[@DefogTech]

Agreed. Especially for release.. similar to lock.unlock()

[@TheRightsville]

Excellent . Your explanations are very clear and concise .

[@berndeckenfels]

Instead of blocking threads you can also put the task in a queue and process that queue with a 3 threads pool. It has also less Synchronisation overhead. Only downside is if you need multiple critical sections like that you get too many pools. And don’t forget to put release in a finally block

[@romandzhadan5546]

simple, clear and great explanantion, thank you!

[@shekhar_2014]

Your way of explaining things are very clean and clear . Thank You somuch ..

[@saravananm2280]

your thumbnail is so aesthetic.

[@shellindebted5328]

It was a pleasure watching and listening to this one.Thanks a lot!

[@DefogTech]

You're welcome sir!

[@venkateshrajendran2362]

Awesome. Very interesting videos on java concurrency

[@UmeshKumar-pq3kc]

Superb explanation. I was looking topic like this. Thanks a lot

[@mizech]

Great explaination of the concept. Thanks a big bunch.

[@anilkinikar]

As always, very good video. 👍🏼

[@ujjvalsharma5055]

great video and I encourage to make more videos like. you are doing a great job

[@111gangadhar]

Awesome...Clear and Consice...

[@abhishekkrishna9757]

Excellent explanation!! if possible, can you please talk about reentrantcy?

[@DefogTech]

Sure, give me few days please, will make one about locks' features like re-entrancy, fairness and such.

[@MegaSriku]

Excellent Content @Defog. I had one question , whatever the semaphore is doing , we could have done the same , if we would have mentioned the fixedThreadPool size as 3. Then internally only three thread at a time could have accessed the shared resource .Or is it like if the the 50 other threads which you instantiating the in the executor, they also have some other tasks(independent) before they hit on the slow service ?

[@ashishmishra6590]

Simply amazing explanation.

[@krish0007]

Really liked your videos. Awesome explanation.

[@madhavarajduraisamy3024]

We can achieve the same functionality if we have only 3 threads in fixed threadpool? . So what is the difference?

[@DefogTech]

True. But what if your tasks have some condition before calling the service (so tasks may or may not call the service). In that case you want to have as many concurrent threads/tasks as possible, and but will need Semaphore to ensure only 3 tasks can call the serve. Similarly, what if there are different types of tasks in a large application which are run by different executor services, or directly by servlet thread pools (which cannot/should-not be restricted). I showed simple example in video to help understand the concept. Generally our applications are slightly more complicated, thus we need such concurrency primitives.

[@corabora6644]

Defog Tech Care to clarify a bit more, please ?

[@reapi_com]

@@DefogTech In theory the semaphore could be shared across multi thread pools right?

[@DefogTech]

Absolutely. Thus, even if there are threads (across pools) accessing our resource, using same semaphore we can restrict the access.

[@DefogTech]

Consider example of a legacy payment service which is very slow, and if there are more than 3 simultaneous connections to the service, it just throws out of memory exception.. Lets say in our application we have multiple features using which user can make payments... for memberships, for buying items, for adding money to their wallet etc. All these features lets say have their own thread pool. How do we ensure, that if there are multiple users all trying payments using different features, we do not overwhelm the legacy service. In this case Semaphore is perfect utility to throttle connections to payment service.

[@vinaykumar-zq9ei]

To create a stream of 1000 counts and submit task , use IntStream.range(1,1000).forEach(i->service.submit(new Task())); rather than Instream.of(1000) as this provides a stream of only one number i.e. 1000.

[@DefogTech]

You are right. Thanks for pointing out!

[@moratorium33]

@@DefogTech lol Nice video, but this confusing me though

[@ofa822]

Nah, this is incorrect because the second argument of range is exclusive and since you are starting it from 1. Total number of tasks will be 999 and not 1000. You need to use rangeClosed(1,1000).

[@chamlyidunil]

cant we use fixed thread pool with size 3 rather than semaphore ?

[@jaikumar73]

Goo explanation. One point though. Shouldn't aquiring and releasing the permits follow the try/finally idiom as an excetpion thrown while holding the permit can never be returned

[@wontonfuton]

It is also worth noting that semophore operations of incrementing and decrementing the count of permits are synchronous.

[@voiceguy554]

Awesome Explanation! Thanks!

[@arnabthakuria2243]

Thank you very concise explanation ..

[@ibrahimshaikh3642]

Nice video, fan Ho Gaya aapka, Please do the same other locking mechanism like mutex

[@vijaykumarreddyt3287]

Great tutorial, Dude

[@alexfeinstein3440]

Great video, thank you!

[@gurupadamgundala5142]

Nice Video sir, please provide some more videos on Threads. Thank you so much for sharing your knowledge with us. Keep it up good work.

[@DefogTech]

You're welcome! Btw, how did you watch the whole video so quick, I uploaded it literally 3 minutes back :)

[@corabora6644]

Defog Tech he mustve had a Semaphore lock on it

[@сойка-и8й]

Any use-case on why would thread want to acquire multiple permits from semaphore ??

[@thomassun3046]

it is nicely explained,here i have a question which is subtle,if the thread calls the release() method and then semaphore has available permits, then the thread which released the lock will go back to the thread pool

[@OmprakashYadavIIT]

Simply Awesome

[@passeam]

Good job!! Could you talk about the bias locking mechanism?

[@PrateekMehtaABDFAN]

Overloaded method of acquireduninterruptably , what can be a use case for this sir ?

[@amanverma9565]

IntStream.of(int) would create stream of single integer, not 1000. In this case only one task is submitted

[@DefogTech]

yeah thats right, was my mistake.. unfortunately cant edit video

[@jonasfreire5943]

Very good that explanation !

[@saurabhhbk]

Are connection pool are made the same concept...

[@jayeshborgaonkar9166]

amazing explanation,

[@sanjaysinghsolanki2953]

Very good video

[@krishnac2512]

What happen if I use newFixedThreadPool(3) instead of 50. ? It acts as semaphore then what is the difference ??

[@DefogTech]

True but what if it's to be used with web request thread pool.. we don't want to reduce size of that threadpool

[@ravipasumarthy8732]

Thank you for these videos. I'm thinking can semaphore be replaced with fixed thread pool? If I replace semaphore with fixed threadpool, the locking may not be within the code, which'll be far away and may not convey the intent. Having said that dynamic permits aren't possible with fixed thread pool. But for simple permits I'm assuming that semaphore can be replaced with fixed threadpool. No of permits = no of threads. What do you say?

[@DefogTech]

Yes you can! Though idiomatically, every lock/semaphore etc should remain close to the resource which is being accessed. Going one step further, its better to encapsulate that object and expose methods which internally use semaphores to guard access. This will ensure no other threads apart from our ThreadPool can ignore the semaphore condition (eg: Web serving thread pool)

[@spaarks84]

I am on my windows machine right now (i.e. no IDE), so I will be lazy and ask the question: Can you use this code to totally parallelize the creation of the Runnables? ```IntStream.of(1000).parallelStream().forEach(...``` In the spirit of the topic, I thought this might be a nice touch.

[@DefogTech]

Yeah absolutely.. I think it should be intstream.of(1,1000)

[@BhawaniSingh-jc7cw]

Great ..Thanks

[@vipinkoul9129]

Very nice explanation. Could you create tutorial on "mutex"? I read many place, "mutex" being referred to as "binary semaphore". I think this is grossly wrong to equate "mutex" to "binary semaphore". Any thread can release a "semaphore", whereas mutex serves exclusivity , and only that thread can release mutex which initially acquired. So I think this is wrong to equate mutex to binary semaphore. Also, what exactly is the of implementation of mutex? Is Lock (e.g. ReentrantLock) a mutex implementation. Can you make a tutorial for clarifying all this?

[@DefogTech]

mutex is same a lock. it is basically using any concurrency tool to ensure 2 threads dont access/change a memory (object) at same time.

[@vipinkoul9129]

@@DefogTech Your tutorials are crystal clear :-)

[@DefogTech]

@@vipinkoul9129 Thanks much!! :)

[@shashankvishwakarma959]

good job !!

[@pulkitbajpai01]

spring cloud hystrix is providing this capability....is this a better way or annoation wrapped spring cloud hystrix

[@DefogTech]

I don't know about hystrix bring available as standalone process. But if your plan is to only use circuit breaker and no other features of service mesh then it's better to use annotation based code and not separate process

[@akshaykumar-uv3up]

In 1 sec if application get 100 requests. If I allow only 3 requests at a time. Meanwhile 3 requests are processing taking a long time then remaining 97 requests are in blocked state?

[@satyanarayanajammala5129]

superb

[@nithesh53]

Awesome

[@jaysreesubaanandavasan5768]

Classic 👍

[@rahulsethione]

I am confused here. Then what is the difference between ExecutionService and Semaphore. It seems they would work the same way. In this case if you create a thread pool of just 3 threads. I think ExecutionService is an alternative to semaphore and a newer API with more features.

[@isaurabh2001]

You have launched 100 threads but based on the condition, they may do entire different work. Out of those 100, suppose only 5 needs to access that lazy resource. In your scenario, all the threads doing same job, that is accessing that lazy resource.

[@rahspit]

Nice presentation...where can I find all these presentations?

[@mahendharkhedhar7887]

Sir would u plz provide a vedio on reentrent locks in java

[@DefogTech]

Yes sir, I am making it.. it might take a while, sorry about the delay.

[@uniquestreetfood8391]

Hi Nice video. One question what will be the difference between synchronize and semaphore with single count. Aren't these same. I tried to search this online but did not any correct answer. Please help !!.

[@DefogTech]

Technically true.. both acheive the same thing. Though in Semaphore, you can timeout on acquire method. In synchronize there is no way to back out.

[@cobra_girl_147]

Thank you vm

[@dipeshiem]

What if my application is deployed in many node ,how we can restrict?

[@DefogTech]

We will need to use distributed semaphores like concept in redis or similar

[@shans8880]

Awesome !!!!!!

[@Improve_Tech_Skills]

thank you ...

[@DefogTech]

You're welcome!

[@shivanshbajpai588]

If Semaphore is releasing a lock and there are 5 threads waiting how is it decided which thread will get a lock Priority of Thread or FCFS or anything else

[@muneeswaranmuneeswaran3768]

At the end of the video, he mentioned a constructor with 'fairness' parameter which allows the long waiting thread to acquire the lock.

[@sagarshekhar6296]

For how many more days we have to wait for Locks/Reentrant locks videos? :)

[@DefogTech]

Maximum 2 more days sir. I have the slides ready. Apologies for the delay

[@Dyslexic_Neuron]

Threadpool or Deadpool ?

[@kennethcarvalho3684]

Circuit breaker

[@suhani091088]

great explanation of a boring and never understandable topic

[@androdeveloper7261]

I would rather use 3 threads so there would no chance of such problem. Anyways.... Using 50 threads and only allowing 3 threads at a time to run doesn't make sense.

[@kirpalsaggu3855]

would have appreciated a better and more practical example

[@maiankithun]

good content with clarity of concept. one correction though IntStream.of(1000).forEach will not run loop for 1000 times. its one element

[@DefogTech]

You are right. It was a miss from my side.