std::thread leads to Abort

[Elysia]

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.

[User Name:]

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.

[Elysia]

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.

[User Name:]

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.

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.