threads vs procceses

My semester starts tomorrow. So I was talking with a guy about sorting algorithms and he suggested me to do a quicksort in two threads for fun. Well the merging would not be parallel, because I have never used threads, so let's keep it simple.
He suggested to use pthread_create, join, and the other function to close the thread.

However, when I lied on the bed, I thought that fork generates a new process and the child process is running -in parallel (??)- with the parent process.

So, why did he suggested me to use threads?

//The course in the university about them comes this semester, so I don't know anything about them :D

I think you are mistaken. Usually a child process has to finish before a parent process continues to run, so it isn't parallel processing.

Might want to look at these:
FAQ > Run a program from within a program - Cprogramming.com
FAQ > Working with Processes - Cprogramming.com

I was asking about it, didn't know. That's why I used the question mark. Tnx

You're mistaken, whiteflags.

The fork() function does create a process, and the two run in parallel (or, at least, scheduled separately), although the parent CAN wait for the child. Some functions (eg system()) do cause the launching program to wait.

To answer the original question, communication between threads within a process is easier, and has less of a performance hit, and less of a demand on system resources as they share the same address space. The system overhead of a thread is typically less than a process (although that is not much of a distinction under unix, where processes are relatively lightweight and threads are relatively heavyweight compared with other operating systems).

The main disadvantage of threads comes from the main advantage: since two threads in a process can access the same memory, it is necessary to explicitly synchronise accesses to any data that is shared between threads, to avoid data corruption and other problems like race conditions that result from two threads attempting to modify the same memory location. In contrast, processes have separate memory spaces, so most interprocess communications methods inherently avoid the need for synchronisation between threads (well - I've fibbed slightly - the operating system can map common memory to two processes, in which case the same synchronisation problems occur).


Threads are not necessarily any more parallel than processes are. That depends on the number of processors (or cores) and also how the operating system schedules processes and threads.

Whether it's processes or threads, both run in parallel.
It's only the standard library system() call in stdlib.h that waits for the child to exit. Everything else has a lot more scope for control.

How you get them to communicate with on another is where the differences arise.

For processes, a parent would use wait() to wait for a child to exit.
For threads, one thread would use pthread_join to wait for another thread to exit.

The wait function can be used to make the parent process wait for the child process to terminate, based on the return value of fork.

I see, thank you very much for your answer :D

So, what would you suggest? Using processes or threads to accomplish my "task"? From Grumpy's post I would say the second..

Well threads all share the same address space, so communicating large volumes of data between threads is easy (so long as you satisfy the mutual exclusion of only one thread accessing it at once).

Getting two processes to share data typically involves using say pipes, files or shared memory.

The idea is to sort [0, middle] and [middle, end] in parallel and then merge them not in parallel. So, threads I suppose is the way I am going to try.

Bear in mind that threads and processes each introduce overhead. It is also necessary to stitch the results from the threads back together .... more overhead. Depending on the size of arrays you're sorting, the overhead of multiple threads/processes can exceed the benefits. You need to test to find out ..... at least, for your target system.

I am only doing this to learn how an algorithm can be executed in parallel. What you say seems logical :)

Not quick sort, but this is how I got started.
http://cboard.cprogramming.com/cplus...ance-gain.html

I had to fix my dad's computer and didn't have the time to code... He has to get serious about how he uses it..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Thanks for the link Manasij, but I won't cheat. When I am done, I will have the look at it for sure :)

The thing is that with these type of algorithms, the speedup you get will be minimal, if any at all. Indeed, you can a huge slowdown.
You should never expect threaded algorithms to always run faster. In practice, they may very well run slower.

Think about it: first you need to synchronize the two (or more) threads. That means some kind of lock, and they are detrimental to performance.
Then you will be modified the same memory (albeit at different addresses). This will cause false sharing to some extent, especially as the two threads get closer to the middle. False sharing will cause data to be flushed forth and back between the processors' cache.
Then, one cpu will need all the data to merge it. That will cause all the data to flow back to the cpu that merges it. Then, all cpus will want the merged data back, causing more data to flow back from the cpu that merged them into the other cpus' caches.

Compare to the single case where no data every needs to leave the cache unless evicted.

It doesn't surprise me that the easiest parallel processing examples are pointless ones.

But quicksort doesn't merge anything ever.

True. But you have two runs sorted. How are you going to get the whole array sorted? An easy solution would be merging the two runs.

Quote:

---

Originally Posted by std10093

However, when I lied on the bed, I thought that fork generates a new process and the child process is running -in parallel (??)- with the parent process.

---

When you lie on the bed, you should only be thinking about Greek girls. Hahaha.

That's a good advice I guess!!! ;)