102: Multithreading. Up And Down.

What if you just want to limit how many things you can have or can be done? This episode will explain another side of the semaphore sometimes called a counting semaphore. When you’re using semaphores, you have a way to wait on the availability of something, but you also really need to have some way to inform the other side when there’s more room to add something. If you really don’t have a need for some other code to run during this, then why have a whole other side in the first place? In this case, all you really need to do is have your thread signal the same semaphore that it waited on when it’s done so that some other thread can have a turn. Just be aware that this isn’t the original intention of semaphores and that you might be overlooking an opportunity to add some extra flexibility to your code by going with a simpler design. And you might even find that what at first seemed like the simpler design just led to more complexities as you try to maintain the “simple” design. If you want to use semaphores like this, then the method names up and down make more sense to me than signal and wait. Listen to the full episode or you can read the full transcript below. Transcript In the last episode, I explained how you can use two semaphores in a producer/consumer situation. You can actually use this anytime you want to send and receive signals from one thread to another. And in this situation, each thread should pick a side and stick with that side of the semaphore. But there are other situations where you’re not really interested in sending signals or in producing and consuming anything. You just want to make sure that there’s a limit of some kind. What do I mean by a limit? We have limits all the time in real life. Not the speed limit type. That’s not the kind of limit I’m talking about. Think of a restaurant that has a maximum capacity limit. For example, only 50 people are allowed inside the building at any given time. In cases like this where you’re not interested in communicating availability of a newly produced item or consumption of something, then the advice about picking a semaphore side and sticking with it becomes clunky. When you enter the restaurant, you’re not really consuming anything. Hopefully, you’ll consume the food but that’s a different story. All you’re really doing is temporarily taking possession of one of the spaces available. And because the possession is temporary, you really should make sure to return it when you’re done. If you don’t, then this would be like leaving the restaurant and taking the chair with you. This means that each thread representing a guest should call wait before entering the restaurant and then call signal when leaving. After reviewing the previous episode, I also try to think of questions that you might have. Is there anything that I could have explained better? And I think I should take the time to explain more about how semaphores work before giving you yet another set of guidelines for how to use them. I mentioned that semaphores have a capacity and a pair of methods such as signal and wait. But what does this mean? Let’s start with a small diner instead of a large restaurant. This diner can only hold 10 guests. What you can do is create a semaphore with a capacity of 10 to match the number of guests. This is the limit. Semaphores work a little backwards that what you might suspect though. Instead of starting out at zero and going up to the limit minus one. Or in this case going from zero to nine. A semaphore instead starts out at the limit. When a guest arrives, the guest should wait on the semaphore. You can think of waiting on a semaphore as similar to locking a mutex. If the semaphore is available, then there’s no wait and the guest can proceed. Just like if the mutex is not currently locked by another thread. When the first guest successfully waits on th