https://bugs.kde.org/show_bug.cgi?id=404842
Bug ID: 404842
Summary: Valgrind introduces a deadlock in program
Product: valgrind
Version: 3.14.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
```c
#include <pthread.h>
#include <stdio.h>
int x = 0;
int y = 0;
void *fn(void *args) {
while (1){
if (x % 10000 == 0) printf("Thread 1: Spinning\n");
y++;
}
}
int main(void) {
pthread_t t;
pthread_create(&t, NULL, fn, NULL);
while(1) {
if (y % 10000 == 0) printf("Thread 0: Spinning\n");
x++;
}
}
```
In the above example, two threads are spinning in a tight-loop, incrementing
their own counter while also checking if another thread's counter has updated
to be modulo some number. Note that this bug occurs even if its modulo some
very small number, like 2.
This seems like a deadlock to me. I'm wondering, when does cooperative yielding
occur? I was scrounging around through the source code and found a lot of stuff
about 'costs' and 'event counters' and even saw that the 'EvC' controls when a
thread will yield the processor. As well, I saw that changes EvC occurs
whenever there is a back-edge and hence a tight spin-loop should cause both
threads to yield often right? Could a combination of this cause the following
scenario...
Thread A acquires 'the_BigLock' and some time passes...
Thread A has an EvC that is almost 0.
Thread A acquires libc's printf lock
Thread A prints message
Thread A encounters some loop while trying to release libc's printf lock
Thread A gets release 'the_BigLock' since EvC is -1.
Thread B gets 'the_BigLock'
Thread B attempts to acquire libc's printf lock
~~~Thread B releases 'the_BigLock'~~~
Is it possible that Thread B tries to acquire libc's printf lock before
releasing 'the_BigLock' causing a deadlock scenario since Thread A has to
acquire 'the_BigLock' before it can continue and release libc's printf lock?
--
You are receiving this mail because:
You are watching all bug changes.
