Talk:Dining philosophers: Difference between revisions
→Two versions in the same language?: Further comment.
(→Contradictory: new section) |
(→Two versions in the same language?: Further comment.) |
||
| (10 intermediate revisions by 6 users not shown) | |||
Line 1:
== grabbing forks ==
'''Python solution''' "If a philosopher acquires one fork but can't acquire the second, he releases the first fork before waiting to acquire the other (which then becomes the first fork acquired)."
Line 8 ⟶ 9:
: Yes, it is possible for this solution to experience livelock. However it can be shown that on a single processor system where threads are timesliced through the processor, that livelock can not occur if the locking loop can execute completely within one timeslice. ( Try acquiring second lock, if fail release first lock, swap forks, loop, acquire first lock ). Since a timeslice is likely to be far longer than the time to execute this loop, you're probably OK. But you would indeed need to guarantee this in your real life system. --[[User:Rldrenth|Rldrenth]] 21:17, 12 May 2009 (UTC)
: While your answer is correct, it exposes that the threads are not "truly" concurrent, they run on the same CPU by a scheduler. They simulate concurrency. Therefore, the greedy strategy of just grabbing the forks one after the other works in practice 99.999% of the time. To trigger a deadlock, one may add an artificial delay between acquiring the forks. That may trick the scheduler to switch threads between the two fork pickups. All this is part of the reason I added the Python multiprocessing version which does true concurrency using multiple CPUs (if avialable). I note that, it seems to me that entering deadlock is only possible if all the philosophers are getting hungry at almost the same time; close enough that a there is no time to pick up two forks before another philosopher can pick one up. If at least one philosopher is not hungry, no deadlock is possible, as is exploited in some algorithms that use a waiter to ensure that only 4 philosophers have access to forks at any given time. I experimented with a pre-generated thinking/dining schedule that can be used to try to trigger a deadlock. I found that it is not that easy to observe a deadlock.[[User:StatusAimSky|StatusAimSky]] ([[User talk:StatusAimSky|talk]]) 04:19, 1 August 2023 (UTC)
There should be examples of output ; for the novice members. --[[User:Arkapravo|Arkapravo]]19:43 , 8 April 2009 (GMT)
Line 70 ⟶ 71:
Since he puts the forks down at the same time,
he will never be holding only one fork.
: What is the contradiction? (A philosopher waits until both forks are available, and then picks them up together, when done, puts them down together. If this were contradictory you should explain what parts of it contradict with which other parts, shouldn't you?) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 01:13, 28 May 2013 (UTC)
What am I missing?
He can't pick up only one fork. He can't put down only one fork.
Yet, "here exist two deadlock states when all five philosophers are sitting at the table holding one fork each."
So, how can a philosopher be holding one fork?
: Oh, yes, I should have read the task. You are right - the task is wrong. Thinking about what the problem is trying to express: philosophers are allowed to pick up individual forks (and, in fact, can only pick up one fork at a time). They just can't eat anything unless they have two forks.
: Paraphrasing: given the reality that a philospher can only pick up one fork at a time, how can we emulate the ideal that philosophers always use two forks together. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 18:37, 4 June 2013 (UTC)
== Delete C++ Boost Version? ==
Would anyone mind if I deleted the C++ Boost version? It's not bad but just dated. Most of the boost features used in the solution have since been adopted by the standard library.
[[User:Garbanzo|Garbanzo]] ([[User talk:Garbanzo|talk]]) 08:43, 13 December 2020 (UTC)
:Removed it. [[User:Garbanzo|Garbanzo]] ([[User talk:Garbanzo|talk]]) 03:47, 7 February 2021 (UTC)
== Two versions in the same language? ==
I wish to add a Python version using multiprocessing instead of threads. [[User:StatusAimSky|StatusAimSky]] ([[User talk:StatusAimSky|talk]]) 06:45, 31 July 2023 (UTC)
:That's often done on RC, either by the original author or some-one else, and is not a problem - just add it under the existing version. However, don't repeat the <nowiki>=={{header|Python}}==</nowiki> part as that will mess up the language stats. --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 07:45, 31 July 2023 (UTC)
:I wonder whether I should remove some functionality from the code I added. What is the aim? A collection of minimal targeted implementations? If so, I will shorten the version just added.[[User:StatusAimSky|StatusAimSky]] ([[User talk:StatusAimSky|talk]]) 03:16, 1 August 2023 (UTC)
::Well, the basic purpose of RC is to compare different programming languages by showing how they'd tackle a given task. So, as long as your code works and meets the task requirements, you're unlikely to be criticized.
::However, there's nothing to stop you doing more than the basics if you think that's not very illuminating or could (within reason) be usefully expanded. With that in mind your additional Python submission seems fine to me and I'd leave it as it is. --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 08:30, 1 August 2023 (UTC)
| |||