这是Geeksforgeeks使用信号量解决用餐哲学家问题的方法:
#include <pthread.h>
#include <semaphore.h>
#include <stdio.h>
#include <unistd.h>
#define N 5
#define THINKING 2
#define HUNGRY 1
#define EATING 0
#define LEFT (phnum + 4) % N
#define RIGHT (phnum + 1) % N
int state[N];
int phil[N] = { 0, 1, 2, 3, 4 };
sem_t mutex;
sem_t S[N];
void test(int phnum)
{
if (state[phnum] == HUNGRY
&& state[LEFT] != EATING
&& state[RIGHT] != EATING) {
// state that eating
state[phnum] = EATING;
sleep(2);
printf("Philosopher %d takes fork %d and %d\n",
phnum + 1, LEFT + 1, phnum + 1);
printf("Philosopher %d is Eating\n", phnum + 1);
// sem_post(&S[phnum]) has no effect
// during takefork
// used to wake up hungry philosophers
// during putfork
sem_post(&S[phnum]);
}
}
// take up chopsticks
void take_fork(int phnum)
{
sem_wait(&mutex);
// state that hungry
state[phnum] = HUNGRY;
printf("Philosopher %d is Hungry\n", phnum + 1);
// eat if neighbours are not eating
test(phnum);
sem_post(&mutex);
// if unable to eat wait to be signalled
sem_wait(&S[phnum]);
sleep(1);
}
// put down chopsticks
void put_fork(int phnum)
{
sem_wait(&mutex);
// state that thinking
state[phnum] = THINKING;
printf("Philosopher %d putting fork %d and %d down\n",
phnum + 1, LEFT + 1, phnum + 1);
printf("Philosopher %d is thinking\n", phnum + 1);
test(LEFT);
test(RIGHT);
sem_post(&mutex);
}
void* philospher(void* num)
{
while (1) {
int* i = num;
sleep(1);
take_fork(*i);
sleep(0);
put_fork(*i);
}
}
int main()
{
int i;
pthread_t thread_id[N];
// initialize the mutexes
sem_init(&mutex, 0, 1);
for (i = 0; i < N; i++)
sem_init(&S[i], 0, 0);
for (i = 0; i < N; i++) {
// create philosopher processes
pthread_create(&thread_id[i], NULL,
philospher, &phil[i]);
printf("Philosopher %d is thinking\n", i + 1);
}
for (i = 0; i < N; i++)
pthread_join(thread_id[i], NULL);
}
https://www.geeksforgeeks.org/dining-philosopher-problem-using-semaphores/
这个代码死锁活锁和饥饿的概率很低,我想改变它,它将有死锁,活锁或饥饿的概率很高,我怎么做?
此外,我如何确保这个解决方案不会有任何这些问题100%(如果可能的话)
好的,首先,我所知道的解决哲学家就餐问题的最佳方案是(来自现代操作系统-第四版Tannebaum和Bos):
#define TRUE 1
#define N 5
#define LEFT (i+N-1)%N
#define RIGHT (i+1)%N
#define THINKING 0
#define HUNGRY 1
#define EATING 2
typedef int semaphore;
int state[N];
semaphore mutex = 1;
semaphore s[N];
void
philosopher(int i){
while(TRUE){
think();
take_forks(i);
eat();
put_forks(i)
}
}
void
take_forks(int i){
down(&mutex);
state[i] = HUNGRY;
test(i);
up(&mutex);
down(&s[i]);
}
void
put_forks(i){
down(&mutex);
state[i] = THINKING;
test(LEFT);
test(RIGHT);
up(&mutex);
}
void
test(int i){
if(state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING){
state[i] = EATING;
up(&s[i]);
}
}
为了简单起见,我们省略了原型和一些函数,但问题是,如果您想创建一个完全不安全的就餐哲学家,解决方案是这样想的:
#define N 5
void philosopher(int i){
while(TRUE){
think();
take_fork(i);
take_fork((i+1)%N);
eat();
put_fork(i);
put_fork((i+1)%N);
}
}
解释:这个程序很容易产生竞争条件,事实上两个哲学家会使用同一个叉子,这是因为我们不使用信号灯等待轮到我们吃东西,它也会产生饥饿,因为我们不使用test()
检查是否有人已经在使用我们的叉子,因此,如果你想修改你的程序来解决这个问题,你应该删除test()
和所有你使用过信号量和任何类型测试的代码。
我已经完成了解决方案。因为在某个时间点,典型的监视器实现会导致饥饿。我已经阅读了这里给出的用餐哲学家问题的“礼貌”版本 那么,如果两个相邻的哲学家同时感到饥饿呢。因为测试(i)是检查它的左派和右派哲学家是否饿了。如果它发现它的邻居也饿了。这是一种僵局,对吗?我的意思是他们两个都不能吃东西,因为他们附近的哲学家家饿了,对吧?
主要内容:死锁,活锁,饥饿,总结本节我们来介绍一下死锁、活锁和饥饿这三个概念。 死锁 死锁是指两个或两个以上的进程(或线程)在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。 死锁发生的条件有如下几种: 1) 互斥条件 线程对资源的访问是排他性的,如果一个线程对占用了某资源,那么其他线程必须处于等待状态,直到该资源
我有一个关于Apache Ignite的问题。我的测试是用一个Ignite服务器(用java编写,使用连续查询来接收更改变量的通知)和一个Ignite客户机(用.NET编写,使用putAll方法发送每50毫秒变化一次的1000个变量的通知)完成的。每个putAll同时发送大约350个变量。我收到的错误是: 2017-07-11 09:56:33,491[警告][网格-超时-工人-#19%null%
我们有一个任务来说明这个问题的僵局。我们已经编写了所有代码,并且代码可以编译,但是当运行代码时,一位哲学家最终吃了东西。所以这不意味着死锁实际上不会发生吗? 这就是输出:输出
问题内容: 该代码实际上是从Java并发中获取的,根据作者的说法,这里发生了“ ThreadStarvtionDeadlock”。请帮我找到ThreadStarvationDeadlock在这里和哪里发生的情况吗?提前致谢。 问题答案: 死锁和饥饿发生在以下行: 怎么样? 如果我们在程序中添加一些额外的代码,它将发生。可能是这样的: 导致死锁的步骤: 通过实现的类将任务提交给渲染页面。 开始在单独
维基百科上说,下面的代码“增加了不允许任何线程饿死的限制”,我不明白为什么没有饿死。例如:如果有很多作者在任何读者之前到达,并且第一个作者花了很长时间完成他的写作,那么r可能会达到一些大的负数,比如说-12345,然后读者开始与作者一起到达,不知怎的,操作系统总是选择writer来接收信号量,而不是reader,如果那样的话,读者会挨饿,这是对的还是我错了?链接:读者和作者问题 请看链接中的第三个