std::thread leads to Abort

I'm trying to code a program for dealing with prime numbers. The idea is to have the prime list readable by all threads, but writeable by 1.

Code:

---

#include "gmpxx.h"

#include <iostream>
#include <thread>
#include <vector>

// primes must be initialised with at least the first two prime numbers.
static std::vector<mpz_class> primes = {2, 3};

// integer sqrt
static mpz_class sqrt(mpz_class n)
{
    mpf_class x, y = n;
   
    do{
        x = y;
        y = (x + n / x) / 2;
    }while(abs(y - x) >= 1);
   
    return y;
}

// extends primes to the lowest prime greater than or equal to n
static void extend_primes(mpz_class n)
{
    // Unfortunately, the primes can't efficiently, if at all, be extended concurrently...
    static std::mutex m;
    std::lock_guard<std::mutex> lock(m);
   
    for(mpz_class i = primes.back() + 2;i <= n;i += 2)
    {
        bool prime = true; // Assume i is prime.
       
        for(auto j = primes.begin();prime && *j <= sqrt(i);j++)
            if(i % *j == 0)
                prime = false;
       
        if(prime)
            primes.push_back(i);
    }
}

int main()
{
    extend_primes(7);
    std::thread t(extend_primes, 19); // This (or a resulting call) must be the cause. When commented out, everything works fine.
   
    for(auto i = primes.begin();i < primes.end();i++)
        std::cout << i->get_str() << " ";
   
    std::cout << std::endl;
    return 0;
}

---

The error:

Code:

---

$ gcc -ggdb -std=c++0x -lstdc++ -lgmp -o prime prime.cpp
$ ./prime
terminate called after throwing an instance of 'std::system_error'
  what(): 
Aborted

---

You start a thread to calculate the primes up to 19, but then immediately go and try outputting the list, whilst the other thread is generating them, and without any locking. Yes I can see why it causes problems, epecially when the vector resizes and all the iterators are invalidated. I assume you understand that the point of a thread is that it doesn't block execution of the thread that created it.
The thing that reads from the list needs to lock also.

Other problems...
You hold the lock whilst generating the entire list of primes. Surely you want a finer grained lock, i.e. only locking as you actually do a push_back? However, once you do that, you wont be able to iterate through the vector using iterators at the same time. I suggest either using a std::list instead, or simply iterating by index. Then you can simultaneously generate primes in one thread and stream them out from other threads.
You're calculating the square root every time through the loop.
I would expect that using mpz_sqrt would at least be faster than hand-rolling a basic iteration method, so why not just use that?

I would like to commend you on your nice use of modern C++ :)

Quote:

---

Originally Posted by iMalc

You start a thread to calculate the primes up to 19, but then immediately go and try outputting the list, whilst the other thread is generating them, and without any locking. Yes I can see why it causes problems, epecially when the vector resizes and all the iterators are invalidated. I assume you understand that the point of a thread is that it doesn't block execution of the thread that created it.
The thing that reads from the list needs to lock also.

---

Okay, so I need a write lock that will lock all write and read locks. I will work on that, but I think I'm still not understanding why it's aborting with the following modification:

Code:

---

static std::mutex m;

static void extend_primes(mpz_class n)
{
        // Unfortunately, the primes can't effeciently, if at all, be extended concurrently...
        std::lock_guard<std::mutex> lock(m);
       
        for(mpz_class i = primes.back() + 2;i <= n;i += 2)
        {
                bool prime = true; // Assume i is prime.
               
                for(auto j = primes.begin();prime && *j <= sqrt(i);j++)
                        if(i % *j == 0)
                                prime = false;
               
                if(prime)
                        primes.push_back(i);
        }
}

int main()
{
        std::thread t(extend_primes, 19);
       
        std::lock_guard<std::mutex> lock(m); // Wait to print
       
        for(auto i = primes.begin();i < primes.end();i++)
                std::cout << i->get_str() << " ";
       
        std::cout << std::endl;
        return 0;
}

---

Quote:

---

Originally Posted by iMalc

You hold the lock whilst generating the entire list of primes. Surely you want a finer grained lock, i.e. only locking as you actually do a push_back? However, once you do that, you wont be able to iterate through the vector using iterators at the same time. I suggest either using a std::list instead, or simply iterating by index. Then you can simultaneously generate primes in one thread and stream them out from other threads.

---

But, if I do that, I can't make the assumption that primes contains all primes from 2 to primes.back(), and from that, it follows that I cannot be certain I have the primes necessary to check if primes.back() + 2 is prime, from which it follows that I cannot generate new primes without resorting to brute force checking. I need to be certain of these properties to be able to use my previously generated primes to do an optimal primality check. I need the lock to make sure I insert, in order, all primes from primes.back() to n. I chose not to use a std::set (for its ordered-ness) because it uses extra complexity that I can avoid by inserting them in order. I get what you mean, it's just that there is a good reason for the coarse grained control I'm using.

Quote:

---

Originally Posted by iMalc

You're calculating the square root every time through the loop.
I would expect that using mpz_sqrt would at least be faster than hand-rolling a basic iteration method, so why not just use that?

---

I didn't know they had an integer square root. Thanks. I was also assuming GCC would optimise away unnecessary sqrt() calls. I will profile it when I'm done, with -03 enabled, and if it dosen't get rid of them, I'll create a temporary and so on.

Quote:

---

Originally Posted by iMalc

I would like to commend you on your nice use of modern C++ :)

---

Thanks. I'm so excited about all the new stuff. I've started like 5 new projects in the last few weeks (since the final draft) just to play with regex, thread, etc.

I'm only going to say say thing now...
What you are doing is wrong, absolutely wrong.
A lock is meant to cause exclusive access to certain resources. This is clearly not what you are trying to do.
What you need is an event. The thread should notify the main function that it has completed, or the main thread can wait until the thread is complete.
What you are doing ends up in a race condition. That is, the code may have two outcomes depending on which thread acquires the lock first.

I'd suggest the later of the two since it's portable. There should be a join member that will block until the thread is finished. Use it.
Unfortunately, to my disappointment, I have not found an easy and portable way of using events. It's a shame, really. Windows supports it gracefully, yet boost neglects to add it.

Sorry I failed to mention this earlier, but join() doesn't work either. It was actually my first try. [In fact, that is why std::mutex m was originally a static local of extend_primes(); it was intended as a mutually exclusive entrance guard for extend_primes(). My later modification was rushed, and admittedly ill conceived.]

Code:

---

int main()
{
        std::thread t(extend_primes, 19);
        t.join();
       
        for(auto i = primes.begin();i < primes.end();i++)
                std::cout << i->get_str() << " ";
       
        std::cout << std::endl;
        return 0;
}

---

Same error.

How does your mpz_class look like?

Um... I'm confused. I didn't code it; it's GMP's.

I see... let's just cut away that part and go with ints then...

Code:

---

#include "gmpxx.h"

#include <cmath>
#include <iostream>
#include <set>
#include <thread>
#include <vector>

// primes must be initialized with at least the first two prime numbers.
static std::vector<int> primes = {2, 3};

static void extend_primes(int n)
{
        // Unfortunately, the primes can't effeciently, if at all, be extended concurrently...
        static std::mutex m;
        std::lock_guard<std::mutex> lock(m);
       
        for(int i = primes.back() + 2;i <= n;i += 2)
        {
                bool prime = true; // Assume i is prime.
               
                for(auto j = primes.begin();prime && *j <= sqrt(i);j++)
                        if(i % *j == 0)
                                prime = false;
               
                if(prime)
                        primes.push_back(i);
        }
}

int main()
{
        std::thread t(extend_primes, 19);
        t.join();
       
        for(auto i = primes.begin();i < primes.end();i++)
                std::cout << *i << " ";
       
        std::cout << std::endl;
        return 0;
}

---

I also cut out my sqrt, since, with ints, it is unnecessary.

Still same error, though.

I still can't reproduce your problem.
My VS10 compliant code if anyone else finds they need it:

Code:

---

#include <cmath>
#include <iostream>
#include <set>
#include <boost/thread.hpp>
#include <vector>
#include <cmath>

// primes must be initialized with at least the first two prime numbers.
static std::vector<int> primes;

static void extend_primes(int n)
{
        // Unfortunately, the primes can't effeciently, if at all, be extended concurrently...
        static boost::mutex m;
        boost::lock_guard<boost::mutex> lock(m);
       
        for(int i = primes.back() + 2;i <= n;i += 2)
        {
                bool prime = true; // Assume i is prime.
               
                for(auto j = primes.begin();prime && *j <= (int)std::sqrt((double)i);j++)
                        if(i % *j == 0)
                                prime = false;
               
                if(prime)
                        primes.push_back(i);
        }
}

int main()
{
        primes.push_back(2);
        primes.push_back(3);

        boost::thread t(extend_primes, 19);
        t.join();
       
        for(auto i = primes.begin();i < primes.end();i++)
                std::cout << *i << " ";
       
        std::cout << std::endl;
        return 0;
}

---

You need to bring out your debugger.

It's GCC 4.5.2's thread implementation, I think.

I made a SMALL test case, and get the same error.

Code:

---

#include <thread>

using namespace std;

void test() {}

int main()
{
        thread t(test);
}

---

Lesson learned: Don't assume standard libraries work like they're supposed to.

That's a pretty big error... is this some alpha release or something?

No, far from it, it ships default with Ubuntu.

I find it very difficult to believe they would just throw in something that is half-finished or doesn't work properly into something such as a distribution...
Well, I dunno. You might try boost's threading facilities until the "bugs" are fixed.

I can't believe they STILL haven't fixed this.

You need to add "-pthread".

http://cboard.cprogramming.com/cplus...-segfault.html

2 years ago!!

A more descriptive error message would be nice...

Apparently if you don't have "-pthread", it would just link in some kind of a stub, that just crashes your program when you call any std::thread function.

t.cpp is the little program above.

Code:

---

$ gcc -ggdb -std=c++0x -lstdc++ -pthread -o t t.cpp
$ ./t
terminate called without an active exception
Aborted

---

Order matters for linking.

... just tell me what to use, please.

"$ gcc -pthread -std=c++0x -lstdc++ -o t t.cpp" doesn't fix it.

I don't know... I'm on Windows right now.

I only remember I had to play with the order of arguments.

On an unrelated (or maybe related) side note, why are you compiling .cpp with gcc and not g++?

I just SSHed into my box. Without -pthread it segfaults, and with -pthread it aborts. So it's probably something totally unrelated.

Works if I add

Code:

---

t.join();

---

gcc is just a wrapper for all the g* compilers. It calls the appropriate compiler based on file suffix. It's just a habit to use gcc and let it decide which g* compiler should be used.

Come now, cyberfish, I shouldn't be the one to tell you this... but quadruple posting? You know there is an edit button, right?

Quote:

---

Originally Posted by cyberfish

Works if I add

Code:

---

t.join();

---

---

Your right... It also works if you add t.detach(). Aren't threads supposed to detach themselves upon deconstruction?

Tehe :).

I found the problem, it's in the code.

Thread is still running when the destructor gets called, and it doesn't like that.

Code:

---

(gdb) r
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d29b70 (LWP 17495)]
terminate called without an active exception
[Thread 0xb7d29b70 (LWP 17495) exited]

Program received signal SIGABRT, Aborted.
0xf57fe416 in __kernel_vsyscall ()
(gdb) bt
#0  0xf57fe416 in __kernel_vsyscall ()
#1  0xb7d55651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d58a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7fa352f in __gnu_cxx::__verbose_terminate_handler() ()
  from /usr/lib/libstdc++.so.6
#4  0xb7fa1465 in ?? () from /usr/lib/libstdc++.so.6
#5  0xb7fa14a2 in std::terminate() () from /usr/lib/libstdc++.so.6
#6  0x08048a50 in ~thread (this=0xbffff7dc, __in_chrg=<value optimized out>)
    at /usr/include/c++/4.4/thread:138
#7  0x080489dd in main () at a.cpp:9

---

Quote:

---

Originally Posted by cyberfish

Tehe :).

I found the problem, it's in the code.

Thread is still running when the destructor gets called, and it doesn't like that.

---

That most definitely sounds like a bug.

Does the standard say anything about that?

It looks pretty deliberate in the header file -

Code:

---


    ~thread()
    {
      if (joinable())
        std::terminate();
    }

---

In /usr/include/c++/4.4/thread line 138.

It boggles your mind, but according to...
c++ - thread destructors in C++0x vs boost - Stack Overflow
...it is the correct behavior.

In other words, we're stuck with a useless thread object -_-
Bye, bye RAII...

There are some discussions here about the "-pthread" switch -
Bug 42198 – [C++0x] Using std::thread without -pthread causes immediate crash

Apparently it's due to -pthread being platform-specific. That's why it's not implied.

Quote:

---

Originally Posted by Elysia

I'm only going to say say thing now...
What you are doing is wrong, absolutely wrong.
A lock is meant to cause exclusive access to certain resources. This is clearly not what you are trying to do.
What you need is an event. The thread should notify the main function that it has completed, or the main thread can wait until the thread is complete.
What you are doing ends up in a race condition. That is, the code may have two outcomes depending on which thread acquires the lock first.

---

An event would be useful if you wanted one thread to generate the primes and then nofity another thread when it was done.
If, as I suggested, someone wanted one thread producing primes and other threads consuming them (which is what I took the original post to mean) then a lock is precisely what you want.
What the OP has here is something where threading is completely pointless. If you create a thread and then immediately join then it is the same as a direct function call.

Yes, it is. I was merely explaining the difference between a lock and an event and in which situation you should use which. In this case, the thread is really pointless as you say.

Useless, until I start using primes in a mt application. For example, I'm going to factor integers with 16 threads. The lock is there to keep more than one thread from entering extend_primes() at the same time. The possibility of more than one needing to extend the list at the same time is rather small. I'm going to go even further and make a unique lock that wakes to check if the primes it's waiting to generate have been generated by the current prime-generating thread (which would happen if I started with primes = 2, 3 had two threads, one generating to 103, which is holding the lock, and another only needing 19, which calls while other is holding the lock; once the first thread has generated primes up to 19, the second will return and continue on its execution).

What I was doing in main() was a simple concept check to get the threading working; it appears y'all assume too quickly that I must be a total fool.

Not asuming you are a fool at all. It just helps a lot to have information that you've now only just provided, a little earlier. I knew there had to be some point to all this, but we could not even determine what you were trying to do, so we didn't know how to advise you.
How do you plan on splitting up the work over multiple threads?
Why don't you start with a decent sized hard-coded list of initial primes?
What size numbers are we talking about here?

Quote:

---

Originally Posted by iMalc

Not asuming you are a fool at all. It just helps a lot to have information that you've now only just provided, a little earlier. I knew there had to be some point to all this, but we could not even determine what you were trying to do, so we didn't know how to advise you.

---

No, there was no initial point. :) I just saw the need to leave the multithreading option open.

Quote:

---

Originally Posted by iMalc

How do you plan on splitting up the work over multiple threads?

---

It will have a per number granularity. I will create a thread for each number, and the thread will compute the factors optimally given the list of primes. There will be a number of threads computing the factors of different numbers. Upon completion of computation, a thread will lock the list of numbers and their factors, add its number and its list, then terminate. The algorithm I'm using to do this, specifically, to save the results and to manage the threads, reeks of kludge, so keep an eye out for a new thread by me. :)

Quote:

---

Originally Posted by iMalc

Why don't you start with a decent sized hard-coded list of initial primes?
What size numbers are we talking about here?

---

Good idea, for later. We're talking about numbers from 2 to n, where n is a number I haven't decided on yet. :P

Quote:

---

Originally Posted by Elysia

It boggles your mind, but according to...
c++ - thread destructors in C++0x vs boost - Stack Overflow
...it is the correct behavior.

In other words, we're stuck with a useless thread object -_-

---

It's not useless. The truth is that there is *no* fully reasonable behavior for destructing a thread object whose thread is still running, and just aborting the application is actually the least of all evils.

Quote:

---

Originally Posted by User Name:

No, there was no initial point. :) I just saw the need to leave the multithreading option open.

It will have a per number granularity. I will create a thread for each number, and the thread will compute the factors optimally given the list of primes. There will be a number of threads computing the factors of different numbers. Upon completion of computation, a thread will lock the list of numbers and their factors, add its number and its list, then terminate. The algorithm I'm using to do this, specifically, to save the results and to manage the threads, reeks of kludge, so keep an eye out for a new thread by me. :)

---

You might find that if you do that, that the overhead of setting up and tearing down a thread for each prime makes is barely faster than just running single threaded, because most numbers are determined to be composite very quickly.
Also, if once a number is prime, you add it to the list, you'll need to handle the possibility that it wont be at the very end of the list because the threads will essentially constantly be completing their jobs in random order.

Quote:

---

Originally Posted by CornedBee

It's not useless. The truth is that there is *no* fully reasonable behavior for destructing a thread object whose thread is still running, and just aborting the application is actually the least of all evils.

---

The problem is that now we are forced to rely on some out-of-scope code instead of the destructor when it comes to threads, and that's why I said useless. We can't rely on RAII with threads.
I fully understand the problem (I read the article), but I don't really fully agree with their solution.
One solution might, for example, be to signal the thread that it should exit. One might also think that it is possible to choose whether to signal the thread to exit or not once the thread goes out of scope.
But IMHO, since RAII is all about objects encapsulating a resource (ie, acquire the resource in the constructor, release in the destructor), it feels like threads shouldn't be an exception. In the constructor, the thread is created and in the destructor, the thread is destroyed.
That would have allowed us to retain RAII semantics. I don't know how feasible it is since I haven't tested it, obviously.

Anyway, useless is my humble opinion.

Quote:

---

Originally Posted by Elysia

One solution might, for example, be to signal the thread that it should exit.

---

Except that there is no standard way to do that. Thread cancellation was removed.

Quote:

---

One might also think that it is possible to choose whether to signal the thread to exit or not once the thread goes out of scope.

---

Well, you can always detach. Of course, detaching comes with its own problems.

Quote:

---

But IMHO, since RAII is all about objects encapsulating a resource (ie, acquire the resource in the constructor, release in the destructor), it feels like threads shouldn't be an exception.

---

Your feeling is wrong. Threads ARE an exception, since they're the only resource that is implicitly referenced by running code (namely, the code running in the thread). When a thread object belonging to a running thread goes out of scope, this implicit reference is dangling, which is dangerous. You can't just kill the thread. You can't signal it, since there is no mechanism for doing so, and anyway there is no telling how long it would take for the thread to react. You can't leave it running, since it violates the expectation that the thread only lives as long as the scope of the thread object. You can't do anything that doesn't lead to subtle bugs, so the decision to do the un-subtle thing is the right one IMO.

He isn't wrong. Threads are the conceptual resources as any other resource object because, as you implied, a thread shouldn't really be allowed to live beyond the object that owns it. If the thread, or the process owning the thread, is to be killed or joined treating the object as conceptually special is silly.

With the mechanism that was chosen, programmers are forced to choose between layering bad exception propagation handling over all code that uses a `std::thread' resource, defaulting to ancient behavior of "just crash it is the best we can do", carefully wrapping the `std::thread' object with higher level code as a means of developing a mechanism for suspending the thread of execution, or developing another object solely to manage the `std::thread' object. All of those options suck! I don't like for my code to "just crash" but that is unfortunately the only option that is easy to get right. (I've already seen a tidy bit of code that fails to do the second option correctly.)

It is true that a `std::thread' object is implicitly referenced by the thread, but so what? As you implied, every possible mechanism is at best a compromise. You agree with the alternative chosen as a "best fit"; a lot of people don't. I certainly don't, but then I don't like "joining" option either. (I like the idea of using constructs that can force termination of the thread, but that is really only yet another compromise and a difficult one to implement correctly.)

The mechanism chosen to prevent a dangling reference invades every aspect of code using a `std::thread' object. I can't simply contain an object and assume the default destructor will do the right thing unless the definition of "right thing" is "crash without context". I can't simply execute my code under the assumption the the error context, the exception objects, I've carefully constructed will be honored because they will not be honored unless I manually wrap the code with a "try" block and "rethrow" the the exception. (Which, personally, I find extremely distasteful in any context and absolutely wrong in most.) I can't just write even the simplest template functions unless I place burdens on the types used with it because I can't know what sorts of exceptions the types might throw and in what context. All of this makes writing and debugging any code using `std::thread' far from easy and I feel that ultimately many will come to the same conclusion and will continue to use other mechanisms for thread management even if it behaves exactly as they may have imagined it should.

Honestly, I don't even disagree with the decision. No, really, I don't, but you can't fault someone for not understanding it.

Soma

Quote:

---

Originally Posted by phantomotap

He isn't wrong.

---

Threads are special. Do you disagree with that?

Quote:

---

Threads are the conceptual resources as any other resource object because, as you implied, a thread shouldn't really be allowed to live beyond the object that owns it.

---

But unlike any other resource, you cannot simply dispose of a thread just like that. (At least any other resource I can think of.)

Quote:

---

The mechanism chosen to prevent a dangling reference invades every aspect of code using a `std::thread' object.

---

True. As would any other.

Quote:

---

I can't simply contain an object and assume the default destructor will do the right thing unless the definition of "right thing" is "crash without context".

---

How do you feel about "hang indefinitely" (cancellation) and "corrupt program state" (termination)?
"Crash without context" is not necessarily true either. GCC is, in my opinion, being stupid here. The least it could do is print a message to stderr saying "destructing unjoined thread object".

Quote:

---

I can't just write even the simplest template functions unless I place burdens on the types used with it because I can't know what sorts of exceptions the types might throw and in what context.

---

I'm not sure what you mean by that. Almost any template function places burdens regarding exceptions on the types you give it.

Quote:

---

All of this makes writing and debugging any code using `std::thread' far from easy and I feel that ultimately many will come to the same conclusion and will continue to use other mechanisms for thread management even if it behaves exactly as they may have imagined it should.

---

I think the problem has been blown way out of proportion. Yes, the OP stumbled across the problem. Yes, he was confused because it's not exactly intuitive. But he noticed the problem and he learned about the special behavior - something he would not have done as readily if the behavior of a destructed thread was something else.

In practice, though, I don't think the problem will occur all that often. Threads are low-level primitives anyway. I expect them to be nicely wrapped up (e.g. in std::async) a lot.

Quote:

---

Originally Posted by CornedBee

Your feeling is wrong. Threads ARE an exception, since they're the only resource that is implicitly referenced by running code (namely, the code running in the thread). When a thread object belonging to a running thread goes out of scope, this implicit reference is dangling, which is dangerous. You can't just kill the thread. You can't signal it, since there is no mechanism for doing so, and anyway there is no telling how long it would take for the thread to react. You can't leave it running, since it violates the expectation that the thread only lives as long as the scope of the thread object. You can't do anything that doesn't lead to subtle bugs, so the decision to do the un-subtle thing is the right one IMO.

---

This is not right.
Because the standard chose to do this, we're stuck with it forever and ever. It's not a mistake they can go back and fix.
The better option, if you ask me, would have been to revoke std::thread from the standard entirely until a safe way to fix this could be proposed. We already have boost, and while not perfect, works. It's not like the standard std::thread would work any better, so would there be any good practical reason to standardize it with such defects?

I cannot now write any good exception-safe code using threads without some sort of special handling code for std::thread in both the thread creating it (making sure to make it so that the thread will be detached in some way before the constructor runs; either by it terminating on its own, detaching or killing it), and in the actual thread whose code we run (to make sure it terminates gracefully).
Pretty? I think not. And now we're stuck with this.

It would be have been far more ideal for the standard to propose a solution to this problem before standardizing std::thread (such as some signal system).

Quote:

---

Threads are special. Do you disagree with that?

---

No. That's exactly the opposite of what I was saying.

You have only chosen to make them special conceptually. A lot of real resources (such as a printer) can be put into a state where the conceptual resource exists beyond the handle (a controlling object) that manages that resource. (I'm not talking about the printer, for example, but the print job associated with our fictional object.)

There are many kinds of resources and I am considering them all. I'm not just comparing purely virtual objects of a probably plentiful nature like RAM or files. I'm comparing both abstract and entirely real resources that may need to be managed. At the very least, they would all be special in the same way.

Quote:

---

But unlike any other resource, you cannot simply dispose of a thread just like that.

---

Considering the printer example again, you can't simply dispose of a print job either. (Actually, you can simply dispose of a print job depending on the platform, but depending on the platform you can also simply dispose of a thread.) With that in mind, it is often necessary to mark the job as terminated, process the job until it can be safely halted, terminate the job, and then free the resource.

In the case of a printer, simply killing the job can jam the physical printer; simply terminating the application would not be a realistic option for many applications. If you tried to wrap this printer resource in "RAII", you'd have to consider and compromise.

Quote:

---

True. As would any other.

---

That is not necessarily true. One of the many other options, "joining" by default for example, may hang in the face of an exception, but the exception context would be processed without the tricks which would be necessary with the chosen mechanism. This approach, too, requires compromise.

Quote:

---

How do you feel about "hang indefinitely" (cancellation) and "corrupt program state" (termination)?

---

The chosen mechanism is process termination so I have no idea why you put that in parentheses in this context. You'll have to explain a little more if you want me to respond to that.

I like the idea of putting mechanisms in place to suspend and then terminate the thread. This would require more primitives and the code path to be threaded would have to be carefully constructed against those primitives. (If it was not so written it might hang indefinitely, but it wouldn't be the standard at fault.) It represents one of many options, but like everything else requires compromise.

Naturally, I don't like the idea of "hang indefinitely", but that need not necessarily be the case; certainly such a mechanism as "terminate the thread" might, but it might only represent a response similar to what already happens by some compilers when an exception is thrown leaving the job, but not necessarily anything else, in a valid but unknown state.

Quote:

---

"Crash without context" is not necessarily true either. GCC is, in my opinion, being stupid here. The least it could do is print a message to stderr saying "destructing unjoined thread object".

---

I know what you are saying. If the compiler provided more context, it would be less of an issue. I'm not sure though that "GCC" is just being stupid. The standard requires that `std::terminate' be called, that static objects for standard objects exist "at least until `main' exits", and also that `std::uncaught_exception()' exists. You'd think that would be enough to ensure that exception context in the case of the issue at hand arising could be processed correctly. It isn't enough for some compilers because of the way exceptions are processed internally. I'm not sure "provide developers with a better standard implementation" is enough for some vendors to change things as much as would be necessary.

*shrug*

Strangely, "GCC" is not such a compiler. You can change the implementation to provide more context without going outside standard C++ with their implementation.

I can't write the code here at this moment, but it is basically using `std::uncaught_exception()' in the context of a terminate handler to "rethrow" and then conditionally reprocess the exception with a series of "catch blocks".

Actually, I'm not sure that still works with "GCC". It would have once worked. If you don't see what I'm talking about but want to try it out let me know.

Quote:

---

I'm not sure what you mean by that. Almost any template function places burdens regarding exceptions on the types you give it.

---

I'm sorry for the confusion. It is absolutely true that many templates place burdens on the types processed. In many cases it is necessary to assume that certain operations will not raise an exception of any kind. It is also true that many operations are assumed to be exception safe even in the face of an exception being raised. Unfortunately, in the case of the chosen mechanism, being exception safe isn't sufficient if I want the template to process that context.

Granted, if the standard required that the context of an exception be processed when this situation occurred this would not be an issue and would not compromise my application. Perhaps we will see that in a further correction to the standard.

Quote:

---

I think the problem has been blown way out of proportion.

---

I agree completely. It doesn't behave in a way that is naturally expected. The chosen mechanism has a lot of issues that must be faced, but so would any other option. It is largely an issue of education.

However, because it doesn't do what so many people expect requiring unfamiliar or unacceptable constructs, I believe that it will be largely ignored.

*shrug*

I don't mean to repeat myself there. You don't see it as an issue, or rather, expect that it will not be an issue once people understand it and how to deal with it. I fully understand; it just happens that I strongly disagree with it.

Soma

Quote:

---

Originally Posted by iMalc

You might find that if you do that, that the overhead of setting up and tearing down a thread for each prime makes is barely faster than just running single threaded, because most numbers are determined to be composite very quickly.
Also, if once a number is prime, you add it to the list, you'll need to handle the possibility that it wont be at the very end of the list because the threads will essentially constantly be completing their jobs in random order.

---

A thread to check each number for prime-ness would be excessive, but that's not what I'm doing. I'm creating a thread to factor each number. I see that one could easily make the argument that prime checking ~ factoring, but the point of it being multithreaded, to the point of having more than 2 threads, is to generate the list of numbers and their factors faster. If all I was doing was creating one thread to factor a number and leaving the original thread to manage it's child, then I would agree, it would be pointless. But, what I'm doing is creating 16 threads constantly factoring numbers with 1 thread managing their creating and joining.

It is factoring that is per thread. Primes are generated in a mutually exclusive function (called by a factoring thread when the list of primes isn't long enough), so as to insure they are inserted in order. The lists of factors are added asynchronously by each thread to a std::map, which maintains order automatically.

EDIT: I started another thread for my logic problems, but it didn't get any replies. Here it is: http://cboard.cprogramming.com/cplus...ithreaded.html

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.

Quote:

---

Originally Posted by 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.

---

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.

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

---

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

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.