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++

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 http://en.cppreferen...om/w/cpp/thread theres also http://www.boost.org...tml/thread.html 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 http://en.wikipedia.org/wiki/Thread_(computer_science) and http://en.wikipedia.org/wiki/Multithreading_(computer_hardware) are a start

In simple terms, a process can only run a single line at a time.

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.

This is useful if you have slow operations such as I/O, or if you want to take advantage of multi-core CPUs.

It is common to use asynchronous I/O, as an example. Instead of having your entire application waiting around to read from the disk, a separate thread can be spawned and the main thread can continue working. Eventually when the data loads the second thread will notify the main thread that it is done. This is such a common thing that it is built into the system.

Another example is 3D rendering. Instead of having the entire application wait for each draw call, the drivers have a separate thread that does the rendering as fast as it can without slowing down your app. It continues to do this unless your app says "Wait for drawing to finish". This is also such a common thing that it is built into the rendering system.

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?

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.

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?

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.

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.

Just wanted to thank everyone in this thread for great, well-written explanations. I'm not the OP, but I did wonder about this. I feel I have at least a basic understanding of the conceptual rammifications of multi-threaded programming now.

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.

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.

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.

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

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.