Member Avatar for shre86

I would like some help regarding multithreading...
i want to know what exactly happens when i start a new thread... i.e how it affects the variables etc. in the program...
one query i have is what happens if i start 2 threads starting with the same function.. will their running be separate from each other or will the changing of the local variables by one affect the other...
and is their anyway to overcome this problem in the case one affects the other...

  • 2 Contributors
  • 2 Replies
  • 97 Views
  • 10 Hours Discussion Span
  • Latest Post Latest Post by shre86

Dani AI

Generated

A short, practical follow-up for building on 's reply: here are concrete patterns and cautions to make two threads running the same function behave independently or safely share state.

A simple and robust pattern is to give each thread its own small "context" object and pass a pointer to it when creating the thread. Allocate that context on the heap (or use thread-local storage) so its lifetime is independent of the creator, and ensure it is freed only after the thread is finished or in the thread itself. Example pattern:

/* allocate a per-thread context, pass it as the start routine arg */
struct worker_args *args = malloc(sizeof *args);
/* fill args->... */
pthread_create(&thr, NULL, worker_fn, args);

/* inside worker_fn(void *v) {
     struct worker_args *a = v;
     /* use a safely */
     free(a);    /* or free after pthread_join in parent */
     return NULL;
} */

Practical tips and pitfalls:

  • Protect shared mutable data with mutexes or other synchronization primitives; use condition variables for coordination. See the pthreads reference for details: pthread functions and semantics.
  • For simple counters or flags prefer atomic operations (C11 stdatomic.h or compiler intrinsics) to avoid full locking overhead.
  • Do not return pointers to local (stack) variables from a thread; that leads to undefined behavior when the stack frame is gone.
  • Manage lifetimes: pthread_join waits for completion; pthread_detach prevents join but transfers responsibility for resources.
  • Race detection helps: use ThreadSanitizer or similar tools to find data races early (ThreadSanitizer docs).

When threads must share state, design the minimal shared surface and protect it. When threads can avoid sharing state, prefer per-thread context or thread-local storage to keep reasoning simple and bugs rare.

Recommended Answers

All 2 Replies

Member Avatar for CrazyDieter

separate threads use different stacks (the part of the memory that stores the local variables) but share the same heap(the part of the memory that stores the objects allocated by 'malloc', or 'new', and global variables).

That means that any changes made on variables allocated on the heap are visible for the other threads, But the local variables are not affected (so no problem if you use the same function for both threads)

Member Avatar for shre86

thanx a lot dude..

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.