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.!!!
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.
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.
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.
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.
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?
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
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
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
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.
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).
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.
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.
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
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.
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 ?
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?
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)
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.
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.
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?
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
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 !!.
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
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.
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?
