What are binary semaphores?

[@Urssaff]

Thank you , your tutorials on semaphores helped me understanding them. Take care and have a good day.

[@seifnaguib1]

I'm sorry but I really did not get how, at 6:02, after removing the binary semaphores, the thread was inside the routine method yet somehow did not increment *fuel (as if it skipped it) and printed the proceeding line normally. How is that possible? I can't quite get that.

[@CodeVault]

The thread basically gets a pointer to already deallocated memory. Which means we are getting undefined behavior. In this case, it's simply pure chance that the value that we have in the currently deallocated memory for fuel is 0 (it could have been anything else)

[@thinhpham7785]

@@CodeVaultthank you for the explaination. I was wondering the same thing as well

[@pandasoli6581]

Difference from binary semaphores and pthread_cond: pthread_cond needs a mutex, and it locks the mutex.

[@saulgoodman6710]

why are we not deallcating after joining the thread? how will the thread execute or how is that routine called before joining the thread?

[@CodeVault]

The routine is automatically called on pthread_create. So, by the time we return from the call pthread_join, the sem_post has been called and we have already deallocated the "fuel"

[@saulgoodman6710]

@@CodeVault Hey Really appreciate your quick reply on a old video! Btw big fan of your videos I've watched all the videos in the playlist and they even helped in my interviews, please keep doing more!

[@nareshchavan8484]

Hi, I had a doubt regarding your implementation 1. When you removed the semaphores the deallocation happens then why doesn't printf in routine function gives an error? 2. After doing sem_post once, sem_wait in main can continue and deallocate the memory, how is it executing both routine threads?

[@CodeVault]

1. It's because the deallocation happens after the sem_wait call. And, since the semaphore is initialized to 0 that sem_wait will wait until sem_post is called on the routine function 2. At 3:52 I set the number of threads to 1. So there's no longer other threads executing that code

[@joemcgoldrick9118]

when you remove the sem_post/sem_wait calls, how come the program doesn't encounter a seg fault on line 17 since you are accessing deallocated memory?

[@CodeVault]

There are a few possible reasons for this: 1) Accessing deallocated memory doesn't guarantee a segfault (that memory could still be unused so you're not accessing memory from another process that you don't have access to) 2) That printf("Deallocating fuel "); in the main function takes way longer than it takes to create the thread and change the fuel value. So the memory didn't have time to be deallocated before used

[@filippo7349]

What will happen if I increment the binary semaphore multiple times (without decrementing it)?

[@CodeVault]

Then it basically just becomes a normal semaphore

[@filippo7349]

@@CodeVault So is it even adequate to differentiate between binary and normal semaphore? Can't see any difference 😅

[@CodeVault]

It's more a conceptual difference in that the semaphore's value should never exceed 1

[@prashantpatil3088]

Which workload should be choose while installing Visual Studia for learning this Linux System Programming

[@kostasrompokas]

Don't install visual studio IDE. Install visual studio code. Also, to be able to run things you need to have a linux OS. If you use windows it gets complicated and you need to install another program called cygwin

[@prashantpatil3088]

@@kostasrompokas thanks for infor👍

[@AnalogDude_]

Would you do a new version of this with 2 threads, one is to top up and one is "consuming" fuel. But the thread to top up the fuel should stop. maybe a 3rd thread to check the fuel content that starts to other thread again to fill up. Another request would be a console program that accepts commands for the user and keeps waiting for a new command, i did this once using GOTO, but the people dislike this as does NASA.

[@CodeVault]

I will look into it

[@AnalogDude_]

cool and thnx.@@CodeVault

[@manuelavendano3891]

Hi there! I've observed that you tend to avoid using constants, instead, you use #define. Is there a particular reason for it? Btw, absolutely remarkable SO tutorials. Have a good one

[@CodeVault]

You can use constants and I actually recommend using them. There was no particular reason for me using macros in this case

[@onursimsek6094]

Let's say we have two different functions one for incrementing the fuel and one for decrementing. Can we use the same 1 semaphore before critical section? Or should we define two different semaphores one of which is used in the increment function and one of which is used in the decrement function?

[@CodeVault]

If you use binary semaphores as mutexes then you need to have the same semaphore. Otherwise... I don't know, depends on what you want to do with those functions

[@onursimsek6094]

@@CodeVault in increment function, I do value++ and in another function, decrement, I do value--. That's just all.

[@CodeVault]

Depends what you want exactly. You need the same one if you use them as mutexes.

[@onursimsek6094]

@@CodeVault Yes, thank you for pointing that out. If you have two different mutexes, when increment function tries to increment the value, at the same time, decrement comes and tries to decrement the value. So, that 's why we need to have the same mutex. When increment tries to increment the value, other threads working on increment, and the threads of decrement will not be able to enter the critical section.

[@novigradmerchant2400]

Is there any performance differences between binary semaphores and mutex?

[@CodeVault]

It's a bit of a wash. Semaphores take a bit more memory than mutexes, but, because mutexes have some extra checks in place it might be a bit more costly. Although nothing significant.

[@narasarajv5278]

Thank you.