I am trying to simulate the boost::thread's timed_join functionality (I know it's deprecated) with calling pthread_timedjoin_np on the native_handle of an std::thread. The problem is that despite joinable() returns true, the join() function throws.
#include <thread>
#include <chrono>
#include <iostream>
int main()
{
auto t = std::thread([]{
std::this_thread::sleep_for(std::chrono::milliseconds{100});
std::cout << "hello from thread\n";
});
struct timespec ts;
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 1;
if (int s = pthread_timedjoin_np(t.native_handle(), nullptr, &ts); s != 0)
{
std::cout << "timed out: " << s << std::endl;
}
if(t.joinable())
{
std::cout << "thread is joinable\n";
t.join();
}
return 0;
}
Everything works if the spawned std::thread is still running when the pthread_timedjoin_np gets called and timed outs of course. Why is this strange behaviour? Isn't it possible to "manipulate" std::thread through its native handle?
If you go behind std::thread's back with native_handle, the standard library has no idea you've done this. Therefore, the result of thread::joinable is not reliable. Or more accurately, "implementation-defined". The implementation might check if the handle has been joined. Or it might not.
So if you intend to manipulate a thread outside of the standard library's control, you need to commit to it. The simplest way would be to have your pthread_timedjoin_np condition detach the thread object if it successfully joined.
Related
I have few queries with respect to below code snapshot.
1) With respect to pthread_create(), assume Thread_1 creates Thread_2. To my understanding Thread_1 can exit without join, but still Thread_2 will keep running. Where as in below example without join() I am not able to run thread and I am seeing exceptions.
2) In few examples I am seeing thread creation without thread object as below. But when I do the same, code is terminated.
std::thread(&Task::executeThread, this);
I am compiling with below command.
g++ filename.cpp -std=c++11 -lpthread
But still it terminate with exception. Is this right way of creating thread or is there any different version of C++ (In my project already they are compiling but not sure about the version).
3) In few examples of my project code, I am seeing below way of creating thread. But I am not able to execute with below example.
std::thread( std::bind(&Task::executeThread, this) );
Below is my code snapshot.
#include <iostream>
#include <thread>
class Task
{
public:
void executeThread(void)
{
for(int i = 0; i < 5; i++)
{
std::cout << " :: " << i << std::endl;
}
}
void startThread(void);
};
void Task::startThread(void)
{
std::cout << "\nthis: " << this << std::endl;
#if 1
std::thread th(&Task::executeThread, this);
th.join(); // Without this join() or while(1) loop, thread will terminate
//while(1);
#elif 0
std::thread(&Task::executeThread, this); // Thread creation without thread object
#else
std::thread( std::bind(&Task::executeThread, this) );
while(1);
#endif
}
int main()
{
Task* taskPtr = new Task();
std::cout << "\ntaskPtr: " << taskPtr << std::endl;
taskPtr->startThread();
delete taskPtr;
return 0;
}
Thanks & Regards
Vishnu Beema
std::thread(&Task::executeThread, this); statement creates and destroys a thread object. The destructor of std::thread invokes std::terminate when the thread wasn't joined or detached (like in your statement).
There is no good reason to use std::bind in C++11 because lambdas are better in terms of space and speed.
When building multi-threaded code you need to specify -pthread option when both compiling and linking. Linker option -lpthread is both inadequate and unnecessary.
By design, you need to join all the threads you spawned, or detach them. See e.g. SO question on join/detach
See also cppreference, detach
Note also important caveats if main() exits while detached threads are still running
I also 100% agree with the comment in the other answer about preferring lambdas to bind.
Finally, do not fall for the temptation to do pthread_cancel on a thread in C++. See e.g pthread_cancel considered harmful
In C++ objects have a lifetime. This is a bit different then dealing with handles in C. In C++ if you create an object on the stack in one scope it will be destroyed if you exit that scope. There are some exception to these rule like std::move, but as a rule of thumb you own the lifetime of an object.
This ties into the same answer as above. When you called std::thread(&Task::executeThread, this); you were actually invoking the thread constructor. This is the start of the thread life and the object lifetime. Notice that you created this object on the stack. If you leave the scope { .. yourcode .. } the DTor will be called. Since you have done this before std::move, join or detatch then std::terminate() is called which is raising the exception.
You can create a thread that way. If you look at the linked documentation for std::thread::thread (constructor) there is an example of an object foo being created the same way. What errors are you receiving?
Relevant Documentation:
a. std::thread::~thread()
b. std::thread::thread
c. Lifetime in C++
I personally would recommend understanding the lifetime of objects in a C++. In short all objects start their lifetime when their constructor is invoked. When they are killed (as in out of scope) their destructor is called. The compiler handles this for you so if you're coming from C its a new concept.
Thank you all for your inputs. I missed thread object as part of thread creation. Because of this though compiling, I am getting exceptions. Below is my updated code. All three scenarios are working fine.
#include <iostream>
#include <thread>
class Task
{
public:
void executeThread(std::string command)
{
for(int i = 0; i < 5; i++)
{
std::cout << command << " :: " << i << std::endl;
}
}
void startThread(void);
std::thread th2;
std::thread th3;
};
void Task::startThread(void)
{
std::cout << "\nthis: " << this << std::endl;
#if 0
std::thread th1(&Task::executeThread, this, "Thread1");
th1.join(); // Without join(), thread will terminate
#elif 0
th2 = std::thread(&Task::executeThread, this, "Thread2");
th2.join();
#else
th3 = std::thread( std::bind(&Task::executeThread, this, "Thread3") );
th3.join();
#endif
}
int main()
{
Task* taskPtr = new Task();
std::cout << "\ntaskPtr: " << taskPtr << std::endl;
taskPtr->startThread();
delete taskPtr;
return 0;
}
In the following code snippet,
void foo() {
std::this_thread::native_handle().... //error here
}
int main() {
std::thread t1(foo);
t1.join();
return 0;
}
How do you get the native_handle from std::this_thread from within the function foo?
There is no way for a thread to autonomously gain access to its own std::thread. This is on purpose since std::thread is a move-only type.
I believe what you're requesting is a native_handle() member of std::thread::id, and that is an interesting suggestion. As far as I know it is not currently possible. It would be used like:
void foo()
{
auto native_me = std::this_thread::get_id().native_handle();
// ...
}
It wouldn't be guaranteed to work, or even exist. However I imagine most POSIX platforms could support it.
One way to try to change the C++ standard is to submit issues. Here are directions on how to do so.
C++11 does not provide a mechanism for getting the current threads native_handle. You must use platform specific calls, i.e. GetCurrentThread() on Windows:
void foo()
{
auto native_me = ::GetCurrentThread();
}
As Howard pointed, there is no support for this in ISO C++ yet.
But thread::id has an overloaded operator<< to print itself to an ostream.
#include <iostream>
#include <thread>
int main()
{
std::cout << "Current thread ID: " << std::this_thread::get_id() << std::endl;
}
Without knowing the semantics of the actual value (which is highly platform-dependent), printing it or using it as a key in a map is the most you should be doing anyway.
Currently(C++17) you can't get native_handle from std::this_thread
The most possible interface might be std::this_thread::native_handle(). But not std::this_thread::get_id().native_handle(); by #Howard
Since Win/Linux/MacOS implement thread and thread::id differently: (below is informal pseudo code)
On Linux native_handle is stored at thread._M_id(of type id)._M_thread.
On Windows native_handle is stored at thread._Thr(of type _Thrd_t, not of type id)._Hnd.
On MacOS native_handle is stored at thread.__t_.
As you can see only in Linux source there is native_hanlde object implemented in thread::id structure. Thus on Win/MacOS you can't get the native_handle from an id object.
Finally, if your code runs only in Linux, there is a dirty trick to get native_handle from this_thread which I will never recommend:
auto thread_id = std::this_thread::get_id();
auto native_handle = *reinterpret_cast<std::thread::native_handle_type*>(&thread_id);
In fact, there is one funny way to circumvent the problem and access it via std::thread , which may work in some cases.
The original example was posted on this blog. I rewritten it.
You can save the code below to test.cpp and compile & run it
:
// g++ ./test.cpp -lpthread && ./a.out
//
#include <thread>
#include <vector>
#include <iostream>
#include <mutex>
#include <sched.h>
#include <pthread.h>
int main(int argc, const char** argv) {
constexpr unsigned num_threads = 4;
// A mutex ensures orderly access to std::cout from multiple threads.
std::mutex iomutex;
std::vector<std::thread> threads(num_threads);
for (unsigned i = 0; i < num_threads; ++i) {
threads[i] = std::thread([&iomutex, i,&threads] {
// Create a cpu_set_t object representing a set of CPUs. Clear it and mark
// only CPU i as set.
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(i, &cpuset);
int rc = pthread_setaffinity_np(threads[i].native_handle(),
sizeof(cpu_set_t), &cpuset);
if (rc != 0) {
std::cerr << "Error calling pthread_setaffinity_np: " << rc << "\n";
}
std::this_thread::sleep_for(std::chrono::milliseconds(20));
while (1) {
{
// Use a lexical scope and lock_guard to safely lock the mutex only
// for the duration of std::cout usage.
std::lock_guard<std::mutex> iolock(iomutex);
std::cout << "Thread #" << i << ": on CPU " << sched_getcpu() << "\n";
}
// Simulate important work done by the tread by sleeping for a bit...
std::this_thread::sleep_for(std::chrono::milliseconds(900));
}
});
}
for (auto& t : threads) {
t.join();
}
return 0;
}
Two thread. Main one is constantly gathering notifications while the other one is processing some of them.
The way i implemet it - is not correct as i've been told. What problems is it causing and what's wrong about it?
#include <iostream>
#include <atomic>
#include <thread>
#include <mutex>
#include <chrono>
std::condition_variable foo;
std::mutex mtx;
void secondThread()
{
while (true)
{
foo.wait(std::unique_lock<std::mutex>(mtx));
std::cout << " ----------------------------" << std::endl;
std::cout << "|processing a notification...|" << std::endl;
std::cout << " ----------------------------" << std::endl;
}
}
int main()
{
std::thread subThread = std::thread(&secondThread);
int count = 0;
while (true)
{
if (count % 10 == 0)
{
foo.notify_one();
}
std::cout << "Main thread working on gathering notifications..." << std::endl;
std::this_thread::sleep_for(std::chrono::milliseconds(300));
count++;
}
return 0;
}
I was told that this foo.wait(std::unique_lock<std::mutex>(mtx)) line of code is not a good practice according to the C++ spec. This is not a proper way of solving this kind of problem. It's also called, sleeping(not busy waiting).
Before you call wait, you must check that the thing you are waiting for hasn't already happened. And before you stop calling wait, you must check that the thing you are waiting for has happened. Condition variables are stateless and have no idea what you're waiting for. It's your job to code that.
Also, the associated mutex must protect the thing you're waiting for. The entire point of a condition variable is to provide an atomic "unlock and wait" operation to prevent this problem:
You check if you need to wait under the protection of a mutex.
You decide you do need to wait.
You unlock the mutex so other threads can make progress.
You wait.
But what if the thing you're waiting for happens after you unlocked the mutex but before you waited? You'll be waiting for something that already happened.
This is why the wait function takes a lock holder -- so that it can perform steps 3 and 4 atomically.
In the following code snippet,
void foo() {
std::this_thread::native_handle().... //error here
}
int main() {
std::thread t1(foo);
t1.join();
return 0;
}
How do you get the native_handle from std::this_thread from within the function foo?
There is no way for a thread to autonomously gain access to its own std::thread. This is on purpose since std::thread is a move-only type.
I believe what you're requesting is a native_handle() member of std::thread::id, and that is an interesting suggestion. As far as I know it is not currently possible. It would be used like:
void foo()
{
auto native_me = std::this_thread::get_id().native_handle();
// ...
}
It wouldn't be guaranteed to work, or even exist. However I imagine most POSIX platforms could support it.
One way to try to change the C++ standard is to submit issues. Here are directions on how to do so.
C++11 does not provide a mechanism for getting the current threads native_handle. You must use platform specific calls, i.e. GetCurrentThread() on Windows:
void foo()
{
auto native_me = ::GetCurrentThread();
}
As Howard pointed, there is no support for this in ISO C++ yet.
But thread::id has an overloaded operator<< to print itself to an ostream.
#include <iostream>
#include <thread>
int main()
{
std::cout << "Current thread ID: " << std::this_thread::get_id() << std::endl;
}
Without knowing the semantics of the actual value (which is highly platform-dependent), printing it or using it as a key in a map is the most you should be doing anyway.
Currently(C++17) you can't get native_handle from std::this_thread
The most possible interface might be std::this_thread::native_handle(). But not std::this_thread::get_id().native_handle(); by #Howard
Since Win/Linux/MacOS implement thread and thread::id differently: (below is informal pseudo code)
On Linux native_handle is stored at thread._M_id(of type id)._M_thread.
On Windows native_handle is stored at thread._Thr(of type _Thrd_t, not of type id)._Hnd.
On MacOS native_handle is stored at thread.__t_.
As you can see only in Linux source there is native_hanlde object implemented in thread::id structure. Thus on Win/MacOS you can't get the native_handle from an id object.
Finally, if your code runs only in Linux, there is a dirty trick to get native_handle from this_thread which I will never recommend:
auto thread_id = std::this_thread::get_id();
auto native_handle = *reinterpret_cast<std::thread::native_handle_type*>(&thread_id);
In fact, there is one funny way to circumvent the problem and access it via std::thread , which may work in some cases.
The original example was posted on this blog. I rewritten it.
You can save the code below to test.cpp and compile & run it
:
// g++ ./test.cpp -lpthread && ./a.out
//
#include <thread>
#include <vector>
#include <iostream>
#include <mutex>
#include <sched.h>
#include <pthread.h>
int main(int argc, const char** argv) {
constexpr unsigned num_threads = 4;
// A mutex ensures orderly access to std::cout from multiple threads.
std::mutex iomutex;
std::vector<std::thread> threads(num_threads);
for (unsigned i = 0; i < num_threads; ++i) {
threads[i] = std::thread([&iomutex, i,&threads] {
// Create a cpu_set_t object representing a set of CPUs. Clear it and mark
// only CPU i as set.
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(i, &cpuset);
int rc = pthread_setaffinity_np(threads[i].native_handle(),
sizeof(cpu_set_t), &cpuset);
if (rc != 0) {
std::cerr << "Error calling pthread_setaffinity_np: " << rc << "\n";
}
std::this_thread::sleep_for(std::chrono::milliseconds(20));
while (1) {
{
// Use a lexical scope and lock_guard to safely lock the mutex only
// for the duration of std::cout usage.
std::lock_guard<std::mutex> iolock(iomutex);
std::cout << "Thread #" << i << ": on CPU " << sched_getcpu() << "\n";
}
// Simulate important work done by the tread by sleeping for a bit...
std::this_thread::sleep_for(std::chrono::milliseconds(900));
}
});
}
for (auto& t : threads) {
t.join();
}
return 0;
}
Is it possible to set a timeout for a call to std::thread::join()? I want to handle the case in which the thread is taking too long to run, or terminate the thread. I may be doing this for multiple threads (say, up to 30).
Preferably without boost, but I'd be interested in a boost solution if that's the best way.
There is no timeout for std::thread::join(). However you can view std::thread::join() as merely a convenience function. Using condition_variables you can create very rich communication and cooperation between your threads, including timed waits. For example:
#include <chrono>
#include <thread>
#include <iostream>
int thread_count = 0;
bool time_to_quit = false;
std::mutex m;
std::condition_variable cv;
void f(int id)
{
{
std::lock_guard<std::mutex> _(m);
++thread_count;
}
while (true)
{
{
std::lock_guard<std::mutex> _(m);
std::cout << "thread " << id << " working\n";
}
std::this_thread::sleep_for(std::chrono::milliseconds(250));
std::lock_guard<std::mutex> _(m);
if (time_to_quit)
break;
}
std::lock_guard<std::mutex> _(m);
std::cout << "thread ended\n";
--thread_count;
cv.notify_all();
}
int main()
{
typedef std::chrono::steady_clock Clock;
std::thread(f, 1).detach();
std::thread(f, 2).detach();
std::thread(f, 3).detach();
std::thread(f, 4).detach();
std::thread(f, 5).detach();
auto t0 = Clock::now();
auto t1 = t0 + std::chrono::seconds(5);
std::unique_lock<std::mutex> lk(m);
while (!time_to_quit && Clock::now() < t1)
cv.wait_until(lk, t1);
time_to_quit = true;
std::cout << "main ending\n";
while (thread_count > 0)
cv.wait(lk);
std::cout << "main ended\n";
}
In this example main launches several threads to do work, all of which occasionally check if it is time to quit under a mutex (this could also be an atomic). The main thread also monitors if it is time to quit (if the threads get all their work done). If main runs out of patience, he just declares it to be time to quit, then waits for all threads to perform any necessary clean up before exiting.
Yes, it is possible. The solution that has been suggested by Galik looks like this:
#include <thread>
#include <future>
...
// Launch the thread.
std::thread thread(ThreadFnc, ...);
...
// Terminate the thread.
auto future = std::async(std::launch::async, &std::thread::join, &thread);
if (future.wait_for(std::chrono::seconds(5))
== std::future_status::timeout) {
/* --- Do something, if thread has not terminated within 5 s. --- */
}
However, this essentially launches a third thread that performs the thread.join().
(Note: The destructor of future will block until thread has joined and the auxiliary thread has terminated.)
Maybe launching a thread just to bring another thread down is not what you want. There is another, portable solution without an auxiliary thread:
#include <thread>
#include <future>
...
// Launch the thread.
std::future<T_return>* hThread
= new std::future<T_return>(std::async(std::launch::async, ThreadFnc, ...));
...
// Terminate the thread.
if (hThread->wait_for(std::chrono::seconds(5))
== std::future_status::timeout) {
/* --- Do something, if thread has not terminated within 5 s. --- */
} else
delete hThread;
where T_return is the return type of your thread procedure. This scenario uses an std::future / std::async combination instead of an std::thread.
Note that hThread is a pointer. When you call the delete operator on it, it will invoke the destructor of *hThread and block until the thread has terminated.
I have tested both versions with gcc 4.9.3 on Cygwin.
Instead of using threads explicitly you can use std::async() to provide you with a std::future<> and you can do timed waits on the std::future:
http://en.cppreference.com/w/cpp/thread/future/wait_for
For Boost, timed_join() is now deprecated. Use try_join_for() instead:
myThread.try_join_for(boost::chrono::milliseconds(8000))
For Boost, see timed_join() for the version of join() with timeout.
The pthread_timedjoin_np() function performs a join-with-timeout. If the thread has not yet terminated, then the call blocks until a maximum time, specified in abstime. If the timeout expires before the thread terminates, the call returns an error.
int pthread_timedjoin_np(pthread_t thread, void **retval, const struct timespec *abstime);
Compile and link with -pthread.