/tech/ - Technology★

>>1020490 (OP)

You mean inside the program you are using multi-threading or you are forking? Because I'm almost certain forks don't share 'global' variables other than env.

Depends principally on your programming language and threading library. Likely shared across threads (not processes). The documentation for your language will be a better help than anyone here, closely followed by a search engine. Also >>733048

I assume you're trying to describe this (I'm assuming you're using pthreads)?

int gVar = 10;
int main() {...}
void *some_thread(void *data_ptr) {
    int lVar = gVar;
    lVar++;
    printf("%d\n", lVar); // prints 11
    printf("%d\n", gVar); // prints 10
}

Value of gVar can be modified if gVar is a pointer.

int *gVar;
int main() {
    gVar = malloc(sizeof(int));
    *gVar = 10; ...}
void *some_thread(void *data_ptr) {
    int *lVar = gVar;
    *lVar = lVar + 1;
    printf("%d\n", *lVar); // prints 11
    printf("%d\n", *gVar); // prints 11
}

Forgot to dereference lVar in addition expression.

>*lVar = lVar + 1;

should be:

>*lVar = *lVar + 1;

>>1020499

You need to use mutex or atomic variables if you want to be correct, right?

>>1020505

Yes, that is if you want to modify the global variable. I'm still not entirely sure what OP wants to do or what the problem actually is.

>>1020490 (OP)

This should probably find its way to the sticky, but global variables are shared across threads, yes. There is no way that I'm aware of to get around this, you'll have to use local variables instead.

Yes, by default global variables are shared between threads. If you want each thread to have its own copy, you can make it thread-local.

In C++11:

thread_local int gVar;

_Thread_local int gVar;

>>1020497

OP here. I'm using "fork()" in Linux.

http://man7.org/linux/man-pages/man2/fork.2.html

>>1020537

If you're creating an entire process rather than just a thread, then obviously the global variables are not going to be shared.

>>1020490 (OP)

This is why mutexes and locks exist anon.

>>1020537

Also, you should read the link you just posted:

>fork() creates a new process by duplicating the calling process.

>The child process and the parent process run in separate memory spaces.

Couldn't be clearer.

>>1020555

i knew forking wouldn't cause problems. i made this thread because im trying to decide between threading and forking. i guess forking is just as good.