Sign in to follow this  
pressgreen

Threads and c++?

Recommended Posts

Can some one just easily explain process or theory behind using threads. I am not quite sure in my many google searches on the subject what the process is exactly. It seems to be a very loaded word that explaines many things. also in some of my searches have led me to believe that it is something that is java specific. is this tru or can it be used with c++. Any light on the subject would be greatly appreciated.

Share this post


Link to post
Share on other sites
[quote name='greenzone' timestamp='1347482836' post='4979446']
also in some of my searches have led me to believe that it is something that is java specific. is this tru or can it be used with c++
[/quote]

I am not entirely sure what you mean by this, are you talking about threading support in C++ or the actual process behind a thread and what happens internally in multithreaded application?

I personally havent done any multithreaded work in C++ but I have briefly looked over C++11 thread library [url="http://en.cppreference.com/w/cpp/thread"]http://en.cppreferen...om/w/cpp/thread[/url] theres also [url="http://www.boost.org/doc/libs/1_51_0/doc/html/thread.html"]http://www.boost.org...tml/thread.html[/url] but I havent dealt with either yet

If you want to understand at a root level what a thread does, I wouldnt know the best place to look but maybe [url="http://en.wikipedia.org/wiki/Thread_(computer_science)"]http://en.wikipedia.org/wiki/Thread_(computer_science)[/url] and [url="http://en.wikipedia.org/wiki/Multithreading_(computer_hardware)"]http://en.wikipedia.org/wiki/Multithreading_(computer_hardware)[/url] are a start [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by Dynamo_Maestro

Share this post


Link to post
Share on other sites
Both responses where very very helpful. in fact i have experienced this problem with I/O when trying to load geometry. the process of loading geometry hangs up the entire program and the more complex the geometry the longer the wait. So from what i understand threading would allow me to load geometry on the side of my program with out halting the main thread? I am assuming it would still take time but it would not stop one from continuing interaction with the main program being run by the main thread?

Share this post


Link to post
Share on other sites
[quote name='greenzone' timestamp='1347486742' post='4979482']
Both responses where very very helpful. in fact i have experienced this problem with I/O when trying to load geometry. the process of loading geometry hangs up the entire program and the more complex the geometry the longer the wait. So from what i understand threading would allow me to load geometry on the side of my program with out halting the main thread? I am assuming it would still take time but it would not stop one from continuing interaction with the main program being run by the main thread?
[/quote]

Yes. Although it sounds very simple, you would need to design your multi-threaded app very carefully. You now have multiple lines of code running concurrently, which thread access which lines first cannot be controlled. This could introduce a slew of bugs that are hard to debug.

A good practice is to keep the code separated between threads. For example, I/O code only accessible by I/O threads.

Share this post


Link to post
Share on other sites
[quote name='greenzone' timestamp='1347486742' post='4979482']
Both responses where very very helpful. in fact i have experienced this problem with I/O when trying to load geometry. the process of loading geometry hangs up the entire program and the more complex the geometry the longer the wait. So from what i understand threading would allow me to load geometry on the side of my program with out halting the main thread? I am assuming it would still take time but it would not stop one from continuing interaction with the main program being run by the main thread?
[/quote]
The thing is that with threads you've change processor timing. As known, processor (let's take single core CPU) can work with only one program at current time, CPU registers can be used only by one application. For example, DOS was single-application system, there you can run only one application simultaneously. Windows becomes the multi-task system, where you can launch few applications simultaneously. But processor is still one-application unit. The goal is that operating system distributes CPU time between few applications that you've ran.
When you create additional thread at OS view point this is "sub-application" that can be executed separately from main application or another thread.

Main problems during multi-threading programming are locks and concurrent data modifications.
Lock appears when one thread needs some data, that can be provided only by another thread, but this thread is to busy and can't answer. So, first thread should do nothing or waiting while another thread will not answered.
Concurrent data modification is situation when two or more threads tries change or use the same data. To resolve such problems, for example, in Java use synchronized methods and data.
C++ has all these problems too. But another sense is that you really can distribute processor time and make your application much faster. You just should find those pieces of code, that can be separated and instantiated as thread. Edited by Deft

Share this post


Link to post
Share on other sites
Also, you should know that your compiler does a lot of parallelization and also optimization such as unrolling, fusion/fision etc and can prob do even more depending on code structure and compiler optimization arguemnts. (it's worth looking in to for many reasons)

This means that a) you can achive some form of parallelization without actually coding it and b) your results might not be as good as you expect it to be (since there is already a lot of optimization going on behind the scenes) or even worse then what the compiler achives for you.

Share this post


Link to post
Share on other sites
[quote name='AlanSmithee' timestamp='1347528853' post='4979640']
This means that a) you can achive some form of parallelization without actually coding it and b) your results might not be as good as you expect it to be (since there is already a lot of optimization going on behind the scenes) or even worse then what the compiler achives for you.
[/quote]

I don't think any compiler would do anything like making your single threaded program multithreaded.
What you think about is probably wide data instructions, like SIMD, that the compiler can insert to process data faster, though still in a single thread.

[quote name='frob' timestamp='1347485493' post='4979466']
If you start a new thread, each thread can run an additional line at the same time. Two threads means twice as many lines. Ten threads mean ten times as many lines.
[/quote]

Not really... you can't run more threads in parallell then you have hardware threads in the CPU. With more os threads, they need to share the cpu threads by classic preemptive multitasking. 2 threads per core on an i7 with hyperthreading enabled. though those threads are not really fully parallel either. And you can benefit from more os threads then hardware threads, since threads needs to stall sometimes waiting for memory and disk. CPU architecture is complicated [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Anyhow, processes and threads are not really part of any programming language, they are part of the OS, and are exposed through various API:s to the programming languages.

In a way, you can see the process as your applications "container" in the OS, while its loaded into RAM, and which keeps record of any memory you have allocated to it, threads started, files opened, etc.
threads are the units of execution in your process, that runs code, and share memory between all other threads in that process.
There is always at least one, the "main thread" (and in c, has the entry point "void main(int argc, char** argv)")

Since threads share memory, any memory accesses they do has to be controlled. This is where thread programming can get messy.
The easiest and (when done right) highest performant solution is to make sure that threads are never accessing the same areas in memory at the same time, by having their own copy of everything they need.
You will always need some synchronisation points, but the less you have, the less risk you have for deadlocks and threads just sleeping waiting for other threads to complete.
Synchronisation is done through special objects called "locks", "mutexes", "semaphores", and probably more names I don't recall now. They all work more or less the same though.

Some programming languages have advanced built in features to make it easier to program multithreaded, and structure your multithreaded program, but it all boils down to semaphores, copying data around, and launching thread entry point functions, in the end. Edited by Olof Hedman

Share this post


Link to post
Share on other sites
Many C++ compilers have OpenMP built in which makes it much easier to program multithreaded software.

It kinda works as a compiler extension that uses preprocessor statements to tell the compiler what code should be run in parallel (Quite similar to Codeplay's Offload SPU compiler extension.)

For cross platform solutions that I want to be really portable across compilers, I use pthread (POSIX) threads and for Windows I use pthreads-win32 (which I assume just acts as a Win32 thread wrapper internally).
The only annoying one is Solaris, which uses different datatypes (so I just make extensive use of the C or C++ preprocessor to get round this). Edited by Karsten_

Share this post


Link to post
Share on other sites
There's a good book describing the multithreading facilities introduced in C++11, "C++ Concurrency in Action: Practical Multithreading" by Anthony Williams.
I'd suggest reading the first two chapters (should answer all your questions and more) available for free here: http://www.manning.com/williams/

Direct links (PDFs):
Sample chapter 1: http://www.manning.com/williams/sample_ch01_CCiA.pdf
Sample chapter 2: http://www.manning.com/williams/sample_ch02_CCiA.pdf

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this