Talk:Dining philosophers: Difference between revisions
→Two versions in the same language?: Further comment.
StatusAimSky (talk | contribs) (two versions in a language) |
(→Two versions in the same language?: Further comment.) |
||
| (3 intermediate revisions by 2 users not shown) | |||
Line 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 89:
== 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)
| |||