Like Tree2Likes

std::thread leads to Abort

This is a discussion on std::thread leads to Abort within the C++ Programming forums, part of the General Programming Boards category; Incidentally, your approach makes the prime function a bottleneck. You might be able to remove that by removing the global ...

  1. #46
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,450
    Incidentally, your approach makes the prime function a bottleneck. You might be able to remove that by removing the global lock when finding new primes.
    Just make sure to lock before each read and write and use indices instead of iterators.

    Also, you may wish to get rid of your dependency on mpz_class. I don't see what it brings, and it means downloading yet another library and configure and set up for those that don't have it.
    Might improve chances of getting an answer.
    Last edited by Elysia; 06-07-2011 at 01:37 PM.
    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.

  2. #47
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    Quote Originally Posted by Elysia View Post
    Incidentally, your approach makes the prime function a bottleneck. You might be able to remove that by removing the global lock when finding new primes.
    Just make sure to lock before each read and write and use indices instead of iterators.
    There are lots of reasons not to do that. If I allow more than 1 thread in the function at the same time, I can no longer assume the list of primes contains all primes from 2 to primes.back(). I follows that I can no longer assume I have the primes necessary to check if a given number is prime without resorting to brute force.

    Instead, if I implement a unique_lock, I can allow other threads that are waiting to generate primes to check if the thread currently generating them has coincidentally generated them up to the point the point they need, thereby allowing the waiting threads to return without generating any primes themselves. In other words, I'm allowing 1 thread, the thread that first gets the mutex, to generate primes for all that are waiting on it.

  3. #48
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,450
    The way you've done it, as far as I am aware... is that you're basically only allowing one thread into the generate primes function. And since you're using a global lock in there, every other thread that has need of that prime list has to wait, even if the primes it needs are finished. That would hurt performance. Am I right in that assumption?

    Instead, if one thread needs more primes, it could start finding more primes, locking as it writes to the list.
    Other threads could check if the primes they need are already found (locking as they check) and if they are, simply lock, read the primes out then unlock and continue as usual.
    This way they don't have to wait until the thread that needs more primes unblocks.
    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.

  4. #49
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    Quote Originally Posted by Elysia View Post
    The way you've done it, as far as I am aware... is that you're basically only allowing one thread into the generate primes function. And since you're using a global lock in there, every other thread that has need of that prime list has to wait, even if the primes it needs are finished. That would hurt performance. Am I right in that assumption?
    Yes, but this is a conceptual prototype. Once I get the multiple threads actually running (see post with link to thread, above) I'm going to implement a lock that allows each thread to check if the primes it needs are generated.

    Quote Originally Posted by Elysia View Post
    Instead, if one thread needs more primes, it could start finding more primes, locking as it writes to the list.
    Other threads could check if the primes they need are already found (locking as they check) and if they are, simply lock, read the primes out then unlock and continue as usual.
    This way they don't have to wait until the thread that needs more primes unblocks.
    This is effectively what I said in my last post, the only difference is that I'm planning on using a unique_lock to implement it.

Page 4 of 4 FirstFirst 1234
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Weird typo leads to interesting result... what does it mean?
    By pollypocket4eva in forum C++ Programming
    Replies: 4
    Last Post: 06-17-2010, 03:30 AM
  2. abort() causes a segfault
    By JFonseka in forum C Programming
    Replies: 12
    Last Post: 04-16-2008, 01:40 AM
  3. abort()
    By swgh in forum C++ Programming
    Replies: 5
    Last Post: 02-22-2008, 03:11 AM
  4. Abort Procedure
    By incognito in forum Windows Programming
    Replies: 5
    Last Post: 01-02-2004, 08:49 PM
  5. Western society leads to unsatisfaction
    By Zewu in forum A Brief History of Cprogramming.com
    Replies: 20
    Last Post: 08-06-2003, 03:45 PM

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