I compared your solution with EWD310, the original Dijkstra paper. I think you corrected a bug in the original source code. Dijkstra does not use "state[i] == HUNGRY" in test(). Did you come up with this correction yourself? I prefer the scoped_lock() solution that is possible since C++17. But Dijkstra did not like the parallel P-operation. This is the problem with genies: they assume that everybody else can do the same.
here State[i] is critical section . when execution moves from take_fork() to test() how it is possible to change from hungry to eating when that section is locked by a mutex?
Actually void putforks() invoke test, so it will wake up suspended process, does not change S[4] to 1 and after returning from test() function it will unlock (mutex). By mistake this faculty wrongly explained the last part
what if P1 comes after P3 and P3 is eating but the lock(mutex) prevents P3 to pass ? couldn't P1 and P3 eat at the same time bcs thier fork L and R are available ?
Baxtexx in solution using mutex what if the first guy who just ate is successful in invoking mutex again (since it's in a while loop) just after the second guy ate every time ? Won't this lead to starvation for others ? I know I'm Missing something ...
2020 and its still the best video i saw about it
Ye perfect explanation and the solutions are really good aswell! Really like the progress of problem to solution
amaaaaaaaaaaaazing extraordinarily explained , literally like a cake walk simple superb
I compared your solution with EWD310, the original Dijkstra paper. I think you corrected a bug in the original source code. Dijkstra does not use "state[i] == HUNGRY" in test(). Did you come up with this correction yourself? I prefer the scoped_lock() solution that is possible since C++17. But Dijkstra did not like the parallel P-operation. This is the problem with genies: they assume that everybody else can do the same.
Nicely explained! Thanks a lot Sir! :)
I LOVE YOU for this, sir. Thanks a ton. :D
You re a man of culture
Well explained, it was helpful. Thanks man!
Thanks so much, it explains very well.
Why don't they eat with just one fork? Do they think forks have separation anxiety?
very well explained.thanks!!
thanks for explanation , have you a code in java or c of this dining philosophers ?
here State[i] is critical section . when execution moves from take_fork() to test() how it is possible to change from hungry to eating when that section is locked by a mutex?
Actually void putforks() invoke test, so it will wake up suspended process, does not change S[4] to 1 and after returning from test() function it will unlock (mutex).
By mistake this faculty wrongly explained the last part
@@bollywoodhub2167 test will bring S[4] to 1 and it will be immediately taken back to 0 by the suspended take_fork of P4. He is right.
The state[i] is locked by the same thread that runs test().
the best , thanks sir
Thankyuu so much sir
Thank you sir
what if P1 comes after P3 and P3 is eating but the lock(mutex) prevents P3 to pass ? couldn't P1 and P3 eat at the same time bcs thier fork L and R are available ?
I think by initializing mutex as N/2 (here 2) we can have a work around. with mutex initialized to 2 P1 and P3 can work together.
are these lectures enough for gate
Thanks a lot
great!
Here is my java implementation for this video: gist.github.com/Baxtex/c34b8931e5675c1fc3d7e6f7be6f84b0
Baxtexx in solution using mutex what if the first guy who just ate is successful in invoking mutex again (since it's in a while loop) just after the second guy ate every time ?
Won't this lead to starvation for others ?
I know I'm Missing something ...
cant the eat in 1 fork lol,