CODEWITHSUNDEEP
c++
Aristona
Aristona

Reputation: 9361

Multi tasking with C++. Threads or different design?

I've always used scripting languages such as PHP where a page runs, completes running and gives an output. However, I want to do something a little different on C++ where I need to multi thread two tasks.

Firstly, the main thread should run, (let's say) a cpu temperature meter which refresh every 1 second, and the second thread should do something else. (like reading all directories under windows directory.)

With that said;

  1. Is using threads are my only chance or can I use a different programming concept for this task?

  2. Especially in gaming, there are loads of things running on the background. For example, AI for NPC's/Monsters, graphic engine, physics engine, player movement, keyboard interaction etc. They work in a single process, so how is it being handled?

Upvotes: 3

Views: 2832

Answers (5)

shawn
shawn

Reputation: 336

You can use multiple threads or multiple processes.

One key difference between threads and processes is that threads share one memory space, whereas each process has its own memory space.

If your tasks need to share objects frequently, e.g. inserting/removing/searching/updating nodes in a graph, multi-threading will allow each thread to access the graph easily with a pointer. This is more difficult with multiple processes.

If your tasks do not share objects frequently, e.g. measure temperature, render image, play music, then you will not see much benefit by sharing one memory space. In that case, multiple processes are better for you.

Upvotes: 0

Eugene Mamin
Eugene Mamin

Reputation: 749

Your challenge presumes task-based concurrency, I think. So, think about it in terms of asynchronous work, not just underlying threads. Howewer, many libraries provides safe, efficient and reliable high-level async API for concurrent tasks. I suggest following:

  1. Qt with QtConcurrent framework.
  2. POCO C++ library with Multithreading subpart.
  3. std::async template from C++11. Or boost::thread for old environments.

I should mention that standard std::async or boost replacement have different issues with task-based concurrency (it doesn't provide many of features to tweak execution policies, e.g. when fork new threads, when steal tasks, etc.)

Upvotes: 2

Olaf Dietsche
Olaf Dietsche

Reputation: 74108

It depends on the concrete tasks and dependencies between them.

When you have unrelated tasks, I would run them in separate processes, no need for threads here. If you have a strong coupling however, multi-threading might be the right answer.

Upvotes: 0

billz
billz

Reputation: 45470

Create a thread for just reading cpu temperature meter and read directory for each second is over kill. No much gain from multi-threads but may have some pain of managing threads. You could put your TASK in a list and schedule them in second manner.

I am not sure about gaming stuff, but I believe they categorize the items/tasks and schedule/check/process in the loop. Some mount of threads are created for some dedicated tasks like socket communication, gui rendering etc, but create a dedicated thread for each item say a creep is over kill.

My suggestion is not to introduce multi-threads so easily into your application if you can do it in one thread. multi-threads will create other side affects like synchronization issue, thread management issue etc.

Upvotes: 3

πάντα ῥεῖ
πάντα ῥεῖ

Reputation: 1

Threads would be the right choice IMHO.

One alternative (OS-dependent) is to fork child processes. Yes, threads are also OS-dependent but at least for C++11 there are standard abstractions for theese. For non C++11 apps it's easy to use the various thread API's provided for the OS or the POSIX pthreads lib if an appropriate port is available.

Another alternative for very simplistic OS's is use so called co-routines instead of threads, e.g. FreeRTOS offers this approach.

To elaborate on your point 2):

This needs to implement some kind of sharing memory to exchange informations and state between the objects running their own threads of execution. Sharing memory needs to use appropriate synchronization mechanisms like mutexes, read/write locks, semaphores, etc.

In some special cases it might make sense to implement your own task scheduling mechanisms instead of relying on the OS. But this also requires some interrupt driven mechanism to switch your tasks execution.

Upvotes: 0

Related Questions