C Mutex not preventing race condition
This is my first attempt at using a mutex with parallel processing to try to make the results come out correctly. I have a simple program which computes the first 25 Fibonacci numbers in parallel threads. When I have the create and join in the same for loop the results are correct. When I put the join in a second for loop this is the output:
Thread[0] created Thread[1] created The fibonacci of 2= -1073741824
Thread[2] created The fibonacci of 2= -1073741824
Thread[3] created The fibonacci of 3= -2147483648
The fibonacci of 4= 1073741824
Thread[4] created The fibonacci of 4= 1073741824
Thread[5] created The fibonacci of 5= -1073741824
Thread[6] created The fibonacci of 7= 455617800
Thread[7] created The fibonacci of 8= 1984977424
Thread[8] created The fibonacci of 8= 1984977424
Thread[9] created The fibonacci of 10= 1985010191
Thread[10] created The fibonacci of 11= 1985042958
Thread[11] created The fibonacci of 11= 1985042958
Thread[12] created The fibonacci of 12= -324914147
Thread[13] created The fibonacci of 13= 1660128811
Thread[14] created The fibonacci of 15= 1660128811
Thread[15] created The fibonacci of 16= 1660128811
Thread[16] created The fibonacci of 16= 1660128811
Thread[17] created The fibonacci of 18= 1660128811
Thread[18] created The fibonacci of 19= 1660128811
Thread[19] created The fibonacci of 20= -974709674
Thread[20] created The fibonacci of 20= -974709674
Thread[21] created The fibonacci of 22= -974709674
Thread[22] created The fibonacci of 23= -974709674
Thread[23] created The fibonacci of 23= -974709674
The fibonacci of 24= -1949419348
Thread[24] created Thread[0] joined & exited
Thread[1] joined & exited
Thread[2] joined & exited
Thread[3] joined & exited
Thread[4] joined & exited
Thread[5] joined & exited
Thread[6] joined & exited
Thread[7] joined & exited
Thread[8] joined & exited
Thread[9] joined & exited
Thread[10] joined & exited
Thread[11] joined & exited
Thread[12] joined & exited
Thread[13] joined & exited
Thread[14] joined & exited
Thread[15] joined & exited
Thread[16] joined & exited
Thread[17] joined & exited
Thread[18] joined & exited
Thread[19] joined & exited
Thread[20] joined & exited
Thread[21] joined & exited
Thread[22] joined & exited
Thread[23] joined & exited
Thread[24] joined & exited
Can you tell me why the mutex isn't keeping the threads processing in the correct order? Here is the program:
#include<stdio.h> //for printf
#include<stdlib.h> //for malloc
#include<pthread.h> //for threading
#define SIZE 25 //number of fibonaccis to be computed
int *fibResults; //array to store fibonacci results
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
//function takes the index for fibResults as a void pointer
//assigns it to an int variable, calculates and prints
//the results of the fibonacci calculations
void *run(void *ptrarg) //executes and exits each thread
{
pthread_mutex_lock (&mutex1);
int arg = *((int *)ptrarg);
if (arg == 0)
{
fibResults[arg] = 0;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else if (arg == 1)
{
fibResults[arg] = 1;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else
{
fibResults[arg] = fibResults[arg -1] + fibResults[arg -2];
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
}
//main function that drives the program.
//Loops through created and joining threads
//passes the index value of the fib array
//to the thread run function
int main()
{
pthread_attr_t a;
fibResults = (int*)malloc (SIZE * sizeof(int));
pthread_attr_init(&a);
pthread_t thread_id[SIZE];
for (int i = 0; i < SIZE; i++)
{
pthread_t thread;
pthread_create(&thread_id[i], &a, run,(void*) &i);
printf("Thread[%d] createdt", i);
fflush(stdout);
}
for (int j = 0; j < SIZE; j++)
{
pthread_join(thread_id[j], NULL);
printf("Thread[%d] joined & exitedn", j);
}
return 0;
}
c multithreading mutex fibonacci
|
show 2 more comments
This is my first attempt at using a mutex with parallel processing to try to make the results come out correctly. I have a simple program which computes the first 25 Fibonacci numbers in parallel threads. When I have the create and join in the same for loop the results are correct. When I put the join in a second for loop this is the output:
Thread[0] created Thread[1] created The fibonacci of 2= -1073741824
Thread[2] created The fibonacci of 2= -1073741824
Thread[3] created The fibonacci of 3= -2147483648
The fibonacci of 4= 1073741824
Thread[4] created The fibonacci of 4= 1073741824
Thread[5] created The fibonacci of 5= -1073741824
Thread[6] created The fibonacci of 7= 455617800
Thread[7] created The fibonacci of 8= 1984977424
Thread[8] created The fibonacci of 8= 1984977424
Thread[9] created The fibonacci of 10= 1985010191
Thread[10] created The fibonacci of 11= 1985042958
Thread[11] created The fibonacci of 11= 1985042958
Thread[12] created The fibonacci of 12= -324914147
Thread[13] created The fibonacci of 13= 1660128811
Thread[14] created The fibonacci of 15= 1660128811
Thread[15] created The fibonacci of 16= 1660128811
Thread[16] created The fibonacci of 16= 1660128811
Thread[17] created The fibonacci of 18= 1660128811
Thread[18] created The fibonacci of 19= 1660128811
Thread[19] created The fibonacci of 20= -974709674
Thread[20] created The fibonacci of 20= -974709674
Thread[21] created The fibonacci of 22= -974709674
Thread[22] created The fibonacci of 23= -974709674
Thread[23] created The fibonacci of 23= -974709674
The fibonacci of 24= -1949419348
Thread[24] created Thread[0] joined & exited
Thread[1] joined & exited
Thread[2] joined & exited
Thread[3] joined & exited
Thread[4] joined & exited
Thread[5] joined & exited
Thread[6] joined & exited
Thread[7] joined & exited
Thread[8] joined & exited
Thread[9] joined & exited
Thread[10] joined & exited
Thread[11] joined & exited
Thread[12] joined & exited
Thread[13] joined & exited
Thread[14] joined & exited
Thread[15] joined & exited
Thread[16] joined & exited
Thread[17] joined & exited
Thread[18] joined & exited
Thread[19] joined & exited
Thread[20] joined & exited
Thread[21] joined & exited
Thread[22] joined & exited
Thread[23] joined & exited
Thread[24] joined & exited
Can you tell me why the mutex isn't keeping the threads processing in the correct order? Here is the program:
#include<stdio.h> //for printf
#include<stdlib.h> //for malloc
#include<pthread.h> //for threading
#define SIZE 25 //number of fibonaccis to be computed
int *fibResults; //array to store fibonacci results
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
//function takes the index for fibResults as a void pointer
//assigns it to an int variable, calculates and prints
//the results of the fibonacci calculations
void *run(void *ptrarg) //executes and exits each thread
{
pthread_mutex_lock (&mutex1);
int arg = *((int *)ptrarg);
if (arg == 0)
{
fibResults[arg] = 0;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else if (arg == 1)
{
fibResults[arg] = 1;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else
{
fibResults[arg] = fibResults[arg -1] + fibResults[arg -2];
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
}
//main function that drives the program.
//Loops through created and joining threads
//passes the index value of the fib array
//to the thread run function
int main()
{
pthread_attr_t a;
fibResults = (int*)malloc (SIZE * sizeof(int));
pthread_attr_init(&a);
pthread_t thread_id[SIZE];
for (int i = 0; i < SIZE; i++)
{
pthread_t thread;
pthread_create(&thread_id[i], &a, run,(void*) &i);
printf("Thread[%d] createdt", i);
fflush(stdout);
}
for (int j = 0; j < SIZE; j++)
{
pthread_join(thread_id[j], NULL);
printf("Thread[%d] joined & exitedn", j);
}
return 0;
}
c multithreading mutex fibonacci
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
3
You're passing in a pointer toi
to your threads, but changingi
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.
– nos
Nov 24 '18 at 1:24
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
1
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07
|
show 2 more comments
This is my first attempt at using a mutex with parallel processing to try to make the results come out correctly. I have a simple program which computes the first 25 Fibonacci numbers in parallel threads. When I have the create and join in the same for loop the results are correct. When I put the join in a second for loop this is the output:
Thread[0] created Thread[1] created The fibonacci of 2= -1073741824
Thread[2] created The fibonacci of 2= -1073741824
Thread[3] created The fibonacci of 3= -2147483648
The fibonacci of 4= 1073741824
Thread[4] created The fibonacci of 4= 1073741824
Thread[5] created The fibonacci of 5= -1073741824
Thread[6] created The fibonacci of 7= 455617800
Thread[7] created The fibonacci of 8= 1984977424
Thread[8] created The fibonacci of 8= 1984977424
Thread[9] created The fibonacci of 10= 1985010191
Thread[10] created The fibonacci of 11= 1985042958
Thread[11] created The fibonacci of 11= 1985042958
Thread[12] created The fibonacci of 12= -324914147
Thread[13] created The fibonacci of 13= 1660128811
Thread[14] created The fibonacci of 15= 1660128811
Thread[15] created The fibonacci of 16= 1660128811
Thread[16] created The fibonacci of 16= 1660128811
Thread[17] created The fibonacci of 18= 1660128811
Thread[18] created The fibonacci of 19= 1660128811
Thread[19] created The fibonacci of 20= -974709674
Thread[20] created The fibonacci of 20= -974709674
Thread[21] created The fibonacci of 22= -974709674
Thread[22] created The fibonacci of 23= -974709674
Thread[23] created The fibonacci of 23= -974709674
The fibonacci of 24= -1949419348
Thread[24] created Thread[0] joined & exited
Thread[1] joined & exited
Thread[2] joined & exited
Thread[3] joined & exited
Thread[4] joined & exited
Thread[5] joined & exited
Thread[6] joined & exited
Thread[7] joined & exited
Thread[8] joined & exited
Thread[9] joined & exited
Thread[10] joined & exited
Thread[11] joined & exited
Thread[12] joined & exited
Thread[13] joined & exited
Thread[14] joined & exited
Thread[15] joined & exited
Thread[16] joined & exited
Thread[17] joined & exited
Thread[18] joined & exited
Thread[19] joined & exited
Thread[20] joined & exited
Thread[21] joined & exited
Thread[22] joined & exited
Thread[23] joined & exited
Thread[24] joined & exited
Can you tell me why the mutex isn't keeping the threads processing in the correct order? Here is the program:
#include<stdio.h> //for printf
#include<stdlib.h> //for malloc
#include<pthread.h> //for threading
#define SIZE 25 //number of fibonaccis to be computed
int *fibResults; //array to store fibonacci results
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
//function takes the index for fibResults as a void pointer
//assigns it to an int variable, calculates and prints
//the results of the fibonacci calculations
void *run(void *ptrarg) //executes and exits each thread
{
pthread_mutex_lock (&mutex1);
int arg = *((int *)ptrarg);
if (arg == 0)
{
fibResults[arg] = 0;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else if (arg == 1)
{
fibResults[arg] = 1;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else
{
fibResults[arg] = fibResults[arg -1] + fibResults[arg -2];
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
}
//main function that drives the program.
//Loops through created and joining threads
//passes the index value of the fib array
//to the thread run function
int main()
{
pthread_attr_t a;
fibResults = (int*)malloc (SIZE * sizeof(int));
pthread_attr_init(&a);
pthread_t thread_id[SIZE];
for (int i = 0; i < SIZE; i++)
{
pthread_t thread;
pthread_create(&thread_id[i], &a, run,(void*) &i);
printf("Thread[%d] createdt", i);
fflush(stdout);
}
for (int j = 0; j < SIZE; j++)
{
pthread_join(thread_id[j], NULL);
printf("Thread[%d] joined & exitedn", j);
}
return 0;
}
c multithreading mutex fibonacci
This is my first attempt at using a mutex with parallel processing to try to make the results come out correctly. I have a simple program which computes the first 25 Fibonacci numbers in parallel threads. When I have the create and join in the same for loop the results are correct. When I put the join in a second for loop this is the output:
Thread[0] created Thread[1] created The fibonacci of 2= -1073741824
Thread[2] created The fibonacci of 2= -1073741824
Thread[3] created The fibonacci of 3= -2147483648
The fibonacci of 4= 1073741824
Thread[4] created The fibonacci of 4= 1073741824
Thread[5] created The fibonacci of 5= -1073741824
Thread[6] created The fibonacci of 7= 455617800
Thread[7] created The fibonacci of 8= 1984977424
Thread[8] created The fibonacci of 8= 1984977424
Thread[9] created The fibonacci of 10= 1985010191
Thread[10] created The fibonacci of 11= 1985042958
Thread[11] created The fibonacci of 11= 1985042958
Thread[12] created The fibonacci of 12= -324914147
Thread[13] created The fibonacci of 13= 1660128811
Thread[14] created The fibonacci of 15= 1660128811
Thread[15] created The fibonacci of 16= 1660128811
Thread[16] created The fibonacci of 16= 1660128811
Thread[17] created The fibonacci of 18= 1660128811
Thread[18] created The fibonacci of 19= 1660128811
Thread[19] created The fibonacci of 20= -974709674
Thread[20] created The fibonacci of 20= -974709674
Thread[21] created The fibonacci of 22= -974709674
Thread[22] created The fibonacci of 23= -974709674
Thread[23] created The fibonacci of 23= -974709674
The fibonacci of 24= -1949419348
Thread[24] created Thread[0] joined & exited
Thread[1] joined & exited
Thread[2] joined & exited
Thread[3] joined & exited
Thread[4] joined & exited
Thread[5] joined & exited
Thread[6] joined & exited
Thread[7] joined & exited
Thread[8] joined & exited
Thread[9] joined & exited
Thread[10] joined & exited
Thread[11] joined & exited
Thread[12] joined & exited
Thread[13] joined & exited
Thread[14] joined & exited
Thread[15] joined & exited
Thread[16] joined & exited
Thread[17] joined & exited
Thread[18] joined & exited
Thread[19] joined & exited
Thread[20] joined & exited
Thread[21] joined & exited
Thread[22] joined & exited
Thread[23] joined & exited
Thread[24] joined & exited
Can you tell me why the mutex isn't keeping the threads processing in the correct order? Here is the program:
#include<stdio.h> //for printf
#include<stdlib.h> //for malloc
#include<pthread.h> //for threading
#define SIZE 25 //number of fibonaccis to be computed
int *fibResults; //array to store fibonacci results
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
//function takes the index for fibResults as a void pointer
//assigns it to an int variable, calculates and prints
//the results of the fibonacci calculations
void *run(void *ptrarg) //executes and exits each thread
{
pthread_mutex_lock (&mutex1);
int arg = *((int *)ptrarg);
if (arg == 0)
{
fibResults[arg] = 0;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else if (arg == 1)
{
fibResults[arg] = 1;
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
else
{
fibResults[arg] = fibResults[arg -1] + fibResults[arg -2];
printf("The fibonacci of %d= %dn", arg, fibResults[arg]);
pthread_mutex_unlock (&mutex1);
pthread_exit(0);
}
}
//main function that drives the program.
//Loops through created and joining threads
//passes the index value of the fib array
//to the thread run function
int main()
{
pthread_attr_t a;
fibResults = (int*)malloc (SIZE * sizeof(int));
pthread_attr_init(&a);
pthread_t thread_id[SIZE];
for (int i = 0; i < SIZE; i++)
{
pthread_t thread;
pthread_create(&thread_id[i], &a, run,(void*) &i);
printf("Thread[%d] createdt", i);
fflush(stdout);
}
for (int j = 0; j < SIZE; j++)
{
pthread_join(thread_id[j], NULL);
printf("Thread[%d] joined & exitedn", j);
}
return 0;
}
c multithreading mutex fibonacci
c multithreading mutex fibonacci
edited Nov 24 '18 at 1:17
efuddy
asked Nov 24 '18 at 1:10
efuddyefuddy
355
355
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
3
You're passing in a pointer toi
to your threads, but changingi
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.
– nos
Nov 24 '18 at 1:24
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
1
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07
|
show 2 more comments
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
3
You're passing in a pointer toi
to your threads, but changingi
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.
– nos
Nov 24 '18 at 1:24
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
1
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
3
3
You're passing in a pointer to
i
to your threads, but changing i
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.– nos
Nov 24 '18 at 1:24
You're passing in a pointer to
i
to your threads, but changing i
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.– nos
Nov 24 '18 at 1:24
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
1
1
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07
|
show 2 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454350%2fc-mutex-not-preventing-race-condition%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454350%2fc-mutex-not-preventing-race-condition%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
When you create a thread and join in the same loop, the threads are serialized, which may explain why the results are correct
– curiousguy12
Nov 24 '18 at 1:18
3
You're passing in a pointer to
i
to your threads, but changingi
in the loop too, which is a race condition. However your biggest issue is that your algorithm requires your threads to run sequentially - i.e. the thread that computes fibonacci(0) must complete before the thread that computes fibbonacci(1) which must complete before your compute fibonacci(2) and so on - defeating any possibility at parallelism.– nos
Nov 24 '18 at 1:24
A mutex doesn't control order, it only controls access. Which is to say that computing Fibonacci numbers with a multi-threaded program is nonsense, since by definition the computations need to be done sequentially (unless you're using the closed form expression).
– user3386109
Nov 24 '18 at 1:27
Would a barrier keep them in order while allowing true parallel processing?
– efuddy
Nov 24 '18 at 1:47
1
The problem here is that now that you have threads executing concurrently, the later threads need to ensure that the data has been set by the earlier threads. The mutex ensures that two threads are not accessing the data, but does nothing to ensure the sequencing. You probably need a condition variable as well as the mutex so that the threads can wait on a condition, check whether the current thread's prerequisites are met, going back to sleep if not, saving its work if it is, and then signalling on the condition so other threads are woken.
– Jonathan Leffler
Nov 24 '18 at 2:07