It's absolutely useless to "find code" for this problem. You just have no idea what you are facing. This is the fundamental study problem used to emphasize the whole problematic area of thread synchronization.
As such, this is not even a problem which is supposed to be "solved". First of all, it is supposed to run into a trouble, with the purpose of illustration of a very subliminal kind of
deadlock. Unlike a "usual" deadlock, when two objects wait for each other, all of the philosophers can come the into state (say, by coming in sync as a result of random timing) that they wait for each other in cycle. Moreover, it's easy to see that it can only happen if all the philosophers come together (more exactly, if there are as many philosophers as the number of dinner come to dinner in the order of sitting). Please see:
Dining philosophers problem — Wikipedia, the free encyclopedia[
^].
No wonder, this problem can be considered as a useful study exercise for the students. There are many, really many different ways to represent philosophers and forks. Just to mention the range: in a typical approach, a fork is represented by a shared resource with
mutual exclusion access (by the way, great illustration of the fact that mutual exclusion synchronization cannot "save" from deadlocks); but in other approach, each fork, as well as a philosopher, is considered as a separate task. On important condition of the model is that no part of the logic should be based on identity of a philosopher or a fork; they should not be identified anyhow.
The study problem usually assume that you create the computer model of this situation using threads or processes, and, at least, illustrate the deadlock. It would be good if you illustrate one or more ways to avoid deadlock and prove their correctness, but this is not so important. It would be good to illustrate the probabilistic nature of the problem, which is very important in practice. It's quite easy to interfere with timing the way that the philosophers "live" for many ears without the deadlock, which will still happen, all of a sudden.
I explained you what's required to perform this study, on a practical, programming part. But where is the code?
Yes, I solved the problem several times, using several different environment and tools, including my own implementation of a multithreading system (without dining philosopher, any proof of concepts cannot be considered seriously :-)), but I'm not going write anything for you.
If you use someone else's code, or if you find some such code anywhere, it will be equivalent to your total failure. That way, the whole purpose of the problem would be defeated. To get real understanding, you need to do the work. This is a once of lifetime chance, because there is only one dining philosophers problem.
And if you find and use some solution created by anyone else, say bye-bye to dining philosophers, and perhaps say bye-bye to multithreading.
—SA
Submit an article or tip