0

I have this code in C:

int X=0;

void main()
{
    X++;
}

How can I let my CPU run this code twice nearly simultaneously on different cores (I'm not asking for 100% success rate for this scenario to happen)?

Maybe thread can help here?

I want to see in my eyes that after running the code X may be 1 and not 2.

If it's important my kernel is non-preemptive (linux 2.4).

  • If you want a full control of which runs on which cores, you might want look into something like [CUDA](https://en.wikipedia.org/wiki/CUDA). If you just want two threads and let the OS schedule them as it sees fit, then just use.. threads. `pthreads` library is pretty standard for Linux – Eugene Sh. Jun 03 '21 at 14:48
  • 2
    In short, you can't, because you don't have fine-grained control what runs when. So, even when starting two threads incrementing that integer, it's unlikely you get other results than 2. However, if you want to demonstrate that incrementing an int isn't reliable without synchronization, I'd suggest repeating this. For example, run four threads and each of them increments the var 1M times. With that setup, and barring a smart compiler, I could imaging actually seeing that race condition. – Ulrich Eckhardt Jun 03 '21 at 14:50
  • @EugeneSh. ok let's make things simpler, I want some code which may cause the scenario I described above (doesn't have to be 100% but even 5% is enough) –  Jun 03 '21 at 14:57
  • @UlrichEckhardt please read my last comment, it doesn't have to be the case for all runs but to theoretically support such behaviour. it's enough for me if from 1000 runs this can happen only once. –  Jun 03 '21 at 14:58
  • XY problem? Why do you care about cores, or things that happen nearly simultaneously (and what's the definition of "nearly")? – n. m. could be an AI Jun 03 '21 at 15:13
  • Re, "5% is enough." How about 0.000005%? Seriously. If each thread only increments the shared variable one time, then the chance of the threads interfering with each other is virtually zero. You'll see something closer to your "5%" if you do as @UlrichEckhardt said, and have each thread increment the variable a million times. – Solomon Slow Jun 03 '21 at 17:21

1 Answers1

1

Hello and welcome to Stackoverflow. Your program could be as simple as

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

int x;

void func(void*) {
    x++;
    printf("x: %d\n", x);
}

int main() {
    pthread_t thread1;
    if (pthread_create(&thread1, NULL, &func, NULL)) {
        perror("Thread creation failed");
    };

    func(NULL);
    pthread_join(thread1, NULL);
}

However what you will get by this is a so called data race or race condition

If you really want to count just something concurrently, then an atomic could be what you need:

#include <stdatomic.h>

atomic_int x;

void func(void*) {
    atomic_fetch_add(&x,1);
    printf("x: %d\n", atomic_load(&x));
}

Furthermore this default thread should still be suitable, and you could use pthread_attr_setschedpolicy but I am not sure otherwise please elaborate more.

Superlokkus
  • 4,731
  • 1
  • 25
  • 57
  • Well if you don't wait on it, then the main thread will finish, which would let the operating system terminate the whole process including the other thread, regardless what it's doing. – Superlokkus Jun 03 '21 at 16:17
  • @daniel, Your `main(...)` function is not the true entry point for the program. The true entry point is in the `libc` library. It sets up the library, it calls your main(...), and then after your main() returns, it tears things down and terminates the process. If you allow your main() function to return while other threads still are running, the library will shut down while those threads still are using it, and it will terminate the process while those threads still have work to do. – Solomon Slow Jun 03 '21 at 17:10
  • @daniel, also note: That behavior is peculiar to C and pthreads. Other programming languages may do things differently. E.g., in Java, the responsibility to shut down the library and kill the process goes to whichever thread finishes last instead of going to the main thread. – Solomon Slow Jun 03 '21 at 17:15