Like Tree4Likes

threads vs procceses

This is a discussion on threads vs procceses within the Tech Board forums, part of the Community Boards category; My semester starts tomorrow. So I was talking with a guy about sorting algorithms and he suggested me to do ...

  1. #1
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675

    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
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,666
    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

  3. #3
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    I was asking about it, didn't know. That's why I used the question mark. Tnx
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,259
    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.
    Aslaville and Elysia like this.
    Right 98% of the time, and don't care about the other 3%.

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,494
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    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
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  7. #7
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    So, what would you suggest? Using processes or threads to accomplish my "task"? From Grumpy's post I would say the second..
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  8. #8
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,494
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  9. #9
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    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.
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  10. #10
    Registered User
    Join Date
    Jun 2005
    Posts
    6,259
    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.
    Right 98% of the time, and don't care about the other 3%.

  11. #11
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    I am only doing this to learn how an algorithm can be executed in parallel. What you say seems logical
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  12. #12
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Not quick sort, but this is how I got started.
    Threaded Merge Sort: No performance gain. :(
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  13. #13
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,675
    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
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,666
    It doesn't surprise me that the easiest parallel processing examples are pointless ones.

    But quicksort doesn't merge anything ever.
    Last edited by whiteflags; 02-17-2013 at 03:55 PM.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 22
    Last Post: 12-14-2012, 10:00 AM
  2. Threads , how? Portable Threads Library?
    By adderly in forum C++ Programming
    Replies: 3
    Last Post: 12-15-2011, 06:54 AM
  3. Threads!
    By bradszy in forum Windows Programming
    Replies: 4
    Last Post: 02-21-2008, 08:54 PM
  4. threads
    By l2u in forum Windows Programming
    Replies: 4
    Last Post: 08-25-2006, 12:06 PM
  5. a point of threads to create multiple threads
    By v3dant in forum C Programming
    Replies: 3
    Last Post: 10-06-2004, 09:48 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21