Creating threads in Constructor

Question

0.00/5 (No votes)

See more:

Is it safe to create threads in constructor.

All threads uses data of the object in which they are created.
I am creating threads after initializing all the member variables.

MyConstructor()
{

//////INITIALIZATION OF MEMBER VARIABLES START
.
.
.
.
.
.
.

//////INITIALIZATION OF MEMBER VARIABLES ENDS


CreateThread( NULL, 0, myThreadProc, this,0,NULL );


}

Posted 16-Jun-11 22:38pm

PrafullaVedante

Updated 16-Jun-11 22:39pm

v2

Add a Solution

4 solutions

Solution 4

I would say its perfectly fine to do so... I've had to create manager classes that start multiple threads and the constructor is where it makes most sense to do so. In a lot of cases, if your thread fails to start, you're going to end the application anyway.

Posted 17-Jun-11 3:02am

Albert Holguin

Comments

Sergey Alexandrovich Kryukov 17-Jun-11 13:38pm

True, a 5.
--SA

Albert Holguin 17-Jun-11 13:40pm

thanks SA

Solution 3

The problem with constructors is that - without a return value - you have no easy way to pass an error state, and you may not throw an exception. So, as C. Pallini already pointed out, you have to deal with all possible causes of failure right within the constructor code.

This may become even trickier when your class contains virtual methods! As SAKryokov pointed out, it is not safe to call virtual methods in a constructor.

To answer your question: No. In general it is not safe. As a rule of thumb, the less functions you call in a constructor, the better! You can do it if you know what you're doing and are capable to deal with all error cases, but it's much safer to do this in a separate function.

Posted 17-Jun-11 1:34am

Stefan_Lang

Comments

CPallini 17-Jun-11 7:45am

You may throw in constructors, of course. See for instance: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.8

Stefan_Lang 17-Jun-11 8:04am

Well, you can, but I don't consider that a good idea:
class MyBad {
public:
MyBad() { throw(); }
};
class MyCompromised {
char p;
MyBad bad;
public:
MyCompromised() {
p = 0;
}
~MyCompromised() {
if (p)
delete [] p;
}
}
};
int main() {
MyCompromised* mc = 0;
try {
mc = new MyCompromised; // <-- throws before executing constructor body
}
catch/* whatever */ {
delete mc; // <-- crash!
}
}
The only 'bad' thing the developer of 'MyCompromised' did is use a member of type 'MyBad'. He can't prevent this, even if he knows that MyBad may throw exceptions, because the exception occurs before the constructor body is even executed. And he may not even know of these exceptions to start with...

CPallini 17-Jun-11 8:11am

As the linked page shows, it is the proper way to handle ctor failure (you should signal the object is not ptoperly initialized). As about your example, you know, deleting a NULL pointer is harmless.

Stefan_Lang 17-Jun-11 8:13am

The point is, p will not be initialized! So the call to delete mc will try to delete [] mc.p which is not initialized to 0!

CPallini 17-Jun-11 8:40am

Nope, beacuse mc is never deleted (is NULL after all). The following code (basically yours with some fixes for syntax errors) runs happily on my system:
class MyBad {
public:

MyBad() { throw "failure"; }
};
class MyCompromised {
char *p;
MyBad bad;
public:
MyCompromised() {
p = 0;
}
~MyCompromised() {
if (p)
delete [] p;
}
};
int main() {
MyCompromised* mc = 0;
try {
mc = new MyCompromised(); // <-- throws before executing constructor body
}
catch(...) {
delete mc; // <-- crash!
}
cout << "hi" << endl;
}

Stefan_Lang 17-Jun-11 8:58am

Ok, you win. I had assumed that an excepted call to new would still return a non-null pointer, But obviously it doesn't.

Thanks for taking the time that I didn't.

Sergey Alexandrovich Kryukov 17-Jun-11 13:40pm

This is not a problem at all. Who passes error state? Only those not using or misusing exception. The idea of passing error state is wrong in first place, so a constructor does not make any difference.
--SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-06-16T22:47:00

Solution 2

It would be unsafe to use virtual functions in C++ constructor (never try it). If you don't do this big mistake, why not? I would only recommend to start the thread later, not in constructor. This is not the rule, just easier to design your code properly.

—SA

Posted 16-Jun-11 22:47pm

Sergey Alexandrovich Kryukov

Comments

CPallini 17-Jun-11 7:51am

Good point. 5.

Sergey Alexandrovich Kryukov 17-Jun-11 13:37pm

Thank you.
--SA

CPallini · Accepted Answer · 2011-06-16T22:46:00

Solution 1

You may do that if you can safely handle (in your object logic) possible CreateThread failures.

Posted 16-Jun-11 22:46pm

CPallini

Comments

Stefan_Lang 17-Jun-11 7:35am

In other words: No. If *he* has to take care of the safety then this means he can *not* 'safely' call CreateThread. ;)

CPallini 17-Jun-11 7:49am

What 'safety'? CreateThread is an API function. You may store its return value and handle errors at any point of the object's lifecycle.
As Sergey pointed out correctly, only the neatness of the design may suffer from such a choice.

Stefan_Lang 17-Jun-11 8:10am

Granted - that was just my built-in Security System answering before getting around to make a sanity check. ;) 'In general' I consider it unsafe to call other functions in a constructor, specifically if it is provided by MS - I've had some bad experiences related to migration to another OS version...

But you're right, CreateThread is safe enough, even MS shouldn't mess it up too badly. :-)

Sergey Alexandrovich Kryukov 17-Jun-11 13:46pm

In other words, "yes". There is nothing unsafe here. Do you think constructors never throw exceptions? It would be not realistic. Code can throw exception and be perfectly safe.
Wrong conclusion.
--SA

Stefan_Lang 20-Jun-11 4:32am

See my responses to C. Pallini - It wasn't a wrong conclusion, just a wrong assumption (i. e. that excepted instantiations would return a non-null pointer).

And with respect to CreateThread being safe - while I haven't noticed any problem with it yet, I've experienced so many very nasty problems with other, presumably 'safe' system functions on Windows that I don't trust any of them. Ever! Ok, maybe when Linus Thorwald open-sources Windows... ;)

Sergey Alexandrovich Kryukov 22-Jun-11 17:21pm

Oh, I see. It all depends. Calling Windows API safe would be a great exaggeration... :-) There are many ways to screw up. :-)
--SA

Sergey Alexandrovich Kryukov 17-Jun-11 13:38pm

...in constructor or not. That's right, my 5.
--SA