Pthread

[celest torrent]

Hello, I'm trying to understand why the final resultt is alsways 20000 ?

#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>

int cpt;

void* f (void* unused){
   if (cpt != 20000){
       cpt++;
       f(NULL);
   }

}

int main(){
   pthread_t tab_processus[10];
   for (int i=0;i<10;i++){
       pthread_create(&tab_processus[i], NULL, f, NULL);
   }

   for (int i=0;i<5;i++){
       pthread_join(tab_processus[i], NULL);
   }
   printf("%d", cpt);
   return 0;
}

[willow shadow]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[celest torrent]

I'm not using a mutex

so there should have some issue with the acces to cpt

and so different values for cpt each time I execute the code

but still it keepps returning 20000

i increased the value to 200000, and I'm getting 20000 or a seg fault

I tried an iterative version and it seems to work

I dont understand why

[dapper crag]

The reason you don't get different results is due to the comparison you made. Using != means that the last thread alive will rarely if ever (probably never) leave the value at anything other than 20000 because if the value is over 20000, it will keep incrementing until the value overflows back into the negatives and then back to 20000

If you used < you would see the value sometimes be over 20000

I'm being dumb

You could still see race conditions with this setup, but due to the fact that you only take one sample of the data and not like 100 (looping this whole thing 100 times) you're unlikely to see the effects. It might take more iterations to see the effects and could take less if the operation was more time intensive than just an increment

Also changing the comparison like I said above could make the race condition more visible

[celest torrent]

I understood that this is unlikely to see a different value for cpt, but I still dont understand why changing the conparison could make the changes more visible

could u describe if there is only two thread a situation where the != make less visible than < ?

I struggle to understand that

[dapper crag]

Because in the current setup, when a race condition happens that pushes cpt above 20000 the other threads keep incrementing it all the way back around to 20000 again, making an unknown number of race conditions invisible. With < the other threads would leave it alone and exit, leaving the race condition visible

[celest torrent]

ohh okk I got it

tyvm !

[dapper crag]

Np

[royal dawn]

Well, to me it looks like you have 10 threads calling a function recursively that increments a global variable along until it gets to 20000 and recursively calls itself, so what result did you expect? It is going to get to 20000 in a matter of microseconds, probably before you can create all 10 threads, and then stop unless of course you overflow the stack with all these recursive calls first.

I have some questions however.

1. Why not initialize cpt to some initial value? I realize it will get zero by default, but why not be explicit?
2. Why not use a lock around access to cpt so as not to lose updates?
3. Why do you pthread_create 10 threads but only pthread_join 5 of them? The upshot of that decision will be that once all 10 threads have been created, you only wait for 5 of them to complete before exiting the program which will kill the remaining 5 at the point.

[celest torrent]

1. Yes u right I just forgot to initialize it
2. Bc I wanted to try without using mutex to see the cpt going over 20000
3. It was a mistake

[mortal lava]

To test race condition like this maybe try writing in a file as a good example.