'Philosophers 42 lock order issue [closed]
I tested my program with Valdgrind --tool=helgrind and I have 2 warning regarding "Thread #5: lock order "0x4A82168 before 0x4A82108" violated"
This is below the original message:
==170652== ---Thread-Announcement------------------------------------------
==170652== ----------------------------------------------------------------
==170652==
==170652== Thread #5: lock order "0x4A82168 before 0x4A82108" violated
==170652==
==170652== Observed (incorrect) order is: acquisition of lock at 0x4A82108
==170652== at 0x483FEDF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==170652== by 0x401902: activity (philo.c:28)
==170652== by 0x401B8B: philo (philo.c:90)
==170652== by 0x4842B1A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==170652== by 0x4872608: start_thread (pthread_create.c:477)
==170652== by 0x49AC162: clone (clone.S:95)
==170652==
==170652== followed by a later acquisition of lock at 0x4A82168
==170652== at 0x483FEDF: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==170652== by 0x401938: activity (philo.c:37)
==170652== by 0x401B8B: philo (philo.c:90)
==170652== by 0x4842B1A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==170652== by 0x4872608: start_thread (pthread_create.c:477)
==170652== by 0x49AC162: clone (clone.S:95)
==170652==
Is this really an issue ?
This is my code below:
void activity(t_philo *philo)
{
pthread_mutex_lock(&philo->left);
pthread_mutex_lock(&philo->info->write_mutex);
print_msg(philo, MSG_FORK);
pthread_mutex_unlock(&philo->info->write_mutex);
if (!philo->right)
{
ft_usleep(philo->info->die * 2);
return ;
}
pthread_mutex_lock(philo->right);
pthread_mutex_lock(&philo->info->write_mutex);
print_msg(philo, MSG_FORK);
pthread_mutex_unlock(&philo->info->write_mutex);
pthread_mutex_lock(&philo->info->write_mutex);
print_msg(philo, MSG_EAT);
pthread_mutex_lock(&philo->info->time_eat);
philo->ms_eat = get_time();
pthread_mutex_unlock(&philo->info->time_eat);
pthread_mutex_unlock(&philo->info->write_mutex);
ft_usleep(philo->info->eat);
if (philo->right)
pthread_mutex_unlock(philo->right);
pthread_mutex_unlock(&philo->left);
sleep_think(philo);
}
Solution 1:[1]
Yes, this is generally an issue.
In general, it is important for all threads to acquire the locks in the same order. Otherwise, if two threads attempt to acquire the same two locks A and B in a different order at the same time, then it could be that the first thread will successfully acquire lock A, and that the second thread will successfully acquire lock B, and now both threads will wait forever attempting to acquire the second lock. This is called a deadlock.
If all threads consistently attempt to acquire all locks in the same order, then there is no danger of a deadlock.
You can read more about this kind of error and why it is important on this page of the valgrind/helgrind documentation. That documentation also specifically refers to the dining philosopher's problem.
It may be possible that you have designed your program in such a way that there is no danger of deadlock, despite the inconsistent lock order. In the comments section, you are claiming that you have eliminated the risk of a deadlock, by introducing a delay for certain philosophers. However, since you are not showing your entire code (or at least a minimal reproducible example), I am unable to tell whether this is true or not.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 |
