CODEWITHSUNDEEP
c++multithreading
GlassFish
GlassFish

Reputation: 14991

What happens if I call an objects member function from a different thread?

If I have an C++ object created in the main thread, and then start another thread, and from that thread I call a public member function of the object I created, what happens?

Is it different if the public function has parameters or if it manipulates private object members?

Does it behave differently on windows, linux or mac os?

What happens if the object is created on the stack?

Upvotes: 14

Views: 8009

Answers (6)

Alok Save
Alok Save

Reputation: 206566

If I have an C++ object created in the main thread, and then start another thread, and from that thread I call a public member function of the object I created, what happens?

It depends on lifetime of the object.

If the object is created on heap(dynamic memory using new) then the other thread will access the members of the object correctly(assuming no race conditions) unless the lifetime of the object ended by calling delete in the first thread.

If the object is created on stack(locally) in the first thread then you will have a *Undefined Behavior*if the lifetime of the created object ended before being accessed in second thread.

Why can you access the object on stack in second thread?

Each thread has its own stack and unless the object created on stack of thread is valid and alive You would be trying to access an address location which doesn't point to any valid object in second thread.
Note that each process has an address space and all threads in the same process share the same address space, hence the address of the variable can be accessed in the second thread. However, You need to ensure that address contains a valid object.

Is it different if the public function has parameters or if it manipulates private object members?

Access specifiers and multithreading are not related at all.
Same access specifier rules apply in all threads.

Does it behave differently on windows, linux or mac os?

The answer to #1 is guaranteed on all Operating systems.

Upvotes: 3

Matthieu M.
Matthieu M.

Reputation: 300029

There are two points that matter:

  • first, as usual, you need to esnure that the lifetime of the instance exceeds the duration of its usage.
  • second, access to variables across multiples threads need be synchronized to prevent race conditions.

That's all folks.

Upvotes: 9

James Kanze
James Kanze

Reputation: 153977

What happens is exactly what happens if you call it from the same thread. The same machine code gets executed. The only potential difference is that you can have several threads accessing the object at the same time; it's up to you to protect against this (at least if any of the threads is modifying the object—otherwise, no protection is needed).

In the case of an object on the stack, you have to consider lifetime issues, but this is the case anyway; save a pointer to an object on the stack in a global variable, then leave the scope where the object was defined, and the global variable becomes a dangling pointer; trying to access the object through it is undefined behavior (and calling a non-static member function on it it is considered using it). Whether the access is from the same thread or a different thread doesn't change anything.

Upvotes: 2

jcoder
jcoder

Reputation: 30035

It will work perfectly well. Objects do not belong to any specific thread and can equally well be called from anywhere.

However, and this is important, calling member function on two threads at the same time will cause problems where you update some data in one thread while reading it in another. You need to either arrange your code to ensure this can't happen, or ensure that your threads coordinate access (using mutex most likely)

Upvotes: 2

Alex
Alex

Reputation: 5439

Compared to the original behaviour there should be no differences if created on the heap. However there are some culprits of course, usually known under the term "thread safety". If you access the same member from different threads, you have to ensurse that accessing the same resources does not lead to a "race condition".

To avoid race conditions you can use different kind of "locks", for instance mutexes etc. When using using lock objects there is another culprit: The danger of "deadlocks", if two accessors wait for each other and the original lock never gets released.

Upvotes: 2

Matthias
Matthias

Reputation: 8180

  1. Each thread has a own stack and thus you can have concurrent streams of execution. It is your own duty to make the object thread-safe.

  2. It does not matter. However, private members are a candidate for race conditions.

  3. If you create an object on the stack, it won't be accessible from another thread.

Upvotes: 4

Related Questions