MacOS C++ CFRunLoopRun() is not blocking a thread - c++

I have this program, which is trying to use MacOS CoreFoundation API CFRunLoopRun() to block a thread.
#include <iostream>
#include <thread>
#include <CoreFoundation/CoreFoundation.h>
CFRunLoopRef loop = nullptr;
int main() {
std::thread t1([](){char n; std::cin>>n; CFRunLoopStop(loop);});
std::thread t2([](){loop=CFRunLoopGetCurrent(); CFRunLoopRun();});
t1.join();
t2.join();
return 0;
}
I am trying to understand why CFRunLoopRun() in thread t2 is not blocking, whereas when if I remove thread t2, and execute same command in main thread then that blocks. what is the right way to call CFRunLoopRun() in t2 thread?

Related

Why does the first code NOT cause a dead-lock

#include <iostream>
#include <thread>
#include <chrono>
#include <mutex>
#include <thread>
std::mutex mtx;
void func2() {
mtx.lock();
std::cout << "here is 2" << std::endl;
mtx.unlock();
}
void func1() {
mtx.lock();
std::cout << "here is 1" << std::endl;
func2();
mtx.unlock();
}
int main() {
func1();
}
but if I modify the main func as follows, it cause dead lock
int main() {
std::thread t1(func1);
t1.join();
}
I complied both two by "g++ test.cpp -std=c++11 -lpthread"
Calling lock in the same thread twice (without unlocking the mutex) is undefined. From cppreference:
If lock is called by a thread that already owns the mutex, the behavior is undefined: for example, the program may deadlock.
It may deadlock. Or it may not. The behavior is undefined.
Note that std::recursive_mutex can be locked multiple times (though only up to some unspecified limit). However, code that needs a recursive mutex is more complicated. In your example it would be easier to remove the locking from func1, because it is only called when the mutex is already locked. In general it isn't that simple.

Access violation on WakeAllConditionVariable in DLL shutdown

I have a situation where I have a worker thread in a DLL (node native module) that uses a std::condition_variable for synchronization. When the executable exits it simply kills my worker threads, and since it's a node native module I have no access to the DLLMain, so I don't know about the impending shutdown.
When I try to notify my (killed and therefore non-existing) thread to shut down with notify_all(), the call simply hangs (on Window 7) or crashes (Windows 10).
After some research I found that the RTL is using a CONDITION_VARIABLE internally. I can reproduce the crash with this little code snippet:
#include <Windows.h>
#include <thread>
#include <condition_variable>
#include <chrono>
std::mutex mutex;
std::condition_variable cond;
CONDITION_VARIABLE win_cond = CONDITION_VARIABLE_INIT;
CRITICAL_SECTION cs;
void worker() {
//std::unique_lock<decltype(mutex)> lock(mutex);
//cond.wait(lock);
EnterCriticalSection(&cs);
SleepConditionVariableCS(&win_cond, &cs, INFINITE);
LeaveCriticalSection(&cs);
}
int main()
{
InitializeCriticalSection(&cs);
std::thread thread(worker);
std::this_thread::sleep_for(std::chrono::seconds(1));
// Simulate DLL shutdown with lpReserved != null
::TerminateThread(thread.native_handle(), 0);
//cond.notify_all();
WakeAllConditionVariable(&win_cond); // crash
thread.join();
return 0;
}
My questions are:
Is it me or is it a bug?
What can I do to fix this / work around?
Note that I would like to continue to use the c++ standard libraries as this code has to run on other OSes then Windows.

ThreadPool with boost::asio does not quit?

I have the following minmal example of a thread pool made with boost::asio.
#include <queue>
#include <map>
#include <boost/shared_ptr.hpp>
#include <boost/asio/io_service.hpp>
#include <boost/thread/thread.hpp>
#include <boost/asio.hpp>
#include <boost/date_time/posix_time/posix_time.hpp> // remove me (only for io)
class ThreadPool
{
public:
void work_as_mainthread(void) { m_io_service.run(); }
ThreadPool(int poolSize = 4) : timer(m_io_service)
{
timer.expires_from_now(boost::posix_time::seconds(1)); // this line does not affect the problem
m_pWork.reset( new boost::asio::io_service::work(m_io_service) );
for ( int i = 0; i < poolSize; ++i)
m_threadGroup.create_thread( boost::bind(&boost::asio::io_service::run, &m_io_service) );
}
~ThreadPool()
{
m_pWork.reset();
m_threadGroup.join_all();
}
private:
boost::asio::io_service m_io_service;
boost::asio::deadline_timer timer;
boost::shared_ptr<boost::asio::io_service::work> m_pWork;
boost::thread_group m_threadGroup;
};
int main()
{
int n_threads = 2;
ThreadPool pool(n_threads);
pool.work_as_mainthread();
// this line is never reached...
return 0;
}
If you like, you can compile it like this:
g++ -Wall -g -lboost_thread -lboost_date_time -lboost_system main.cpp -o main
What makes me wonder is that the program does not stop. What I do is calling io_service::run, but without any "work" for it. io_services without work quit themselves, as said in the boost::asio docs. Now, why does my program never quit?
When you create a boost::asio::io_service::work object, that keeps the io_service from completing.
// This line keeps the io_service running
m_pWork.reset( new boost::asio::io_service::work(m_io_service) );
If you want it to stop, you would need to destroy that work object, like this:
// stop the worker(s)
m_pWork.reset();
It's up to you to find an appropriate time/place to do this. I would suggest calling timer.async_wait(), then in the handler you can reset your work object to see how this all should be working together.
See this portion of the documentation.

C++ terminate called without an active exception

I am getting a C++ error with threading:
terminate called without an active exception
Aborted
Here is the code:
#include <queue>
#include <thread>
#include <mutex>
#include <condition_variable>
template<typename TYPE>
class blocking_stream
{
public:
blocking_stream(size_t max_buffer_size_)
: max_buffer_size(max_buffer_size_)
{
}
//PUSH data into the buffer
blocking_stream &operator<<(TYPE &other)
{
std::unique_lock<std::mutex> mtx_lock(mtx);
while(buffer.size()>=max_buffer_size)
stop_if_full.wait(mtx_lock);
buffer.push(std::move(other));
mtx_lock.unlock();
stop_if_empty.notify_one();
return *this;
}
//POP data out of the buffer
blocking_stream &operator>>(TYPE &other)
{
std::unique_lock<std::mutex> mtx_lock(mtx);
while(buffer.empty())
stop_if_empty.wait(mtx_lock);
other.swap(buffer.front());
buffer.pop();
mtx_lock.unlock();
stop_if_full.notify_one();
return *this;
}
private:
size_t max_buffer_size;
std::queue<TYPE> buffer;
std::mutex mtx;
std::condition_variable stop_if_empty,
stop_if_full;
bool eof;
};
I modeled my code around this example:
http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html
What am I doing wrong and how do I fix the error?
When a thread object goes out of scope and it is in joinable state, the program is terminated. The Standard Committee had two other options for the destructor of a joinable thread. It could quietly join -- but join might never return if the thread is stuck. Or it could detach the thread (a detached thread is not joinable). However, detached threads are very tricky, since they might survive till the end of the program and mess up the release of resources. So if you don't want to terminate your program, make sure you join (or detach) every thread.
How to reproduce that error:
#include <iostream>
#include <stdlib.h>
#include <string>
#include <thread>
using namespace std;
void task1(std::string msg){
cout << "task1 says: " << msg;
}
int main() {
std::thread t1(task1, "hello");
return 0;
}
Compile and run:
el#defiant ~/foo4/39_threading $ g++ -o s s.cpp -pthread -std=c++11
el#defiant ~/foo4/39_threading $ ./s
terminate called without an active exception
Aborted (core dumped)
You get that error because you didn't join or detach your thread.
One way to fix it, join the thread like this:
#include <iostream>
#include <stdlib.h>
#include <string>
#include <thread>
using namespace std;
void task1(std::string msg){
cout << "task1 says: " << msg;
}
int main() {
std::thread t1(task1, "hello");
t1.join();
return 0;
}
Then compile and run:
el#defiant ~/foo4/39_threading $ g++ -o s s.cpp -pthread -std=c++11
el#defiant ~/foo4/39_threading $ ./s
task1 says: hello
The other way to fix it, detach it like this:
#include <iostream>
#include <stdlib.h>
#include <string>
#include <unistd.h>
#include <thread>
using namespace std;
void task1(std::string msg){
cout << "task1 says: " << msg;
}
int main()
{
{
std::thread t1(task1, "hello");
t1.detach();
} //thread handle is destroyed here, as goes out of scope!
usleep(1000000); //wait so that hello can be printed.
}
Compile and run:
el#defiant ~/foo4/39_threading $ g++ -o s s.cpp -pthread -std=c++11
el#defiant ~/foo4/39_threading $ ./s
task1 says: hello
Read up on detaching C++ threads and joining C++ threads.
Eric Leschinski and Bartosz Milewski have given the answer already. Here, I will try to present it in a more beginner friendly manner.
Once a thread has been started within a scope (which itself is running on a thread), one must explicitly ensure one of the following happens before the thread goes out of scope:
The runtime exits the scope, only after that thread finishes executing. This is achieved by joining with that thread. Note the language, it is the outer scope that joins with that thread.
The runtime leaves the thread to run on its own. So, the program will exit the scope, whether this thread finished executing or not. This thread executes and exits by itself. This is achieved by detaching the thread. This could lead to issues, for example, if the thread refers to variables in that outer scope.
Note, by the time the thread is joined with or detached, it may have well finished executing. Still either of the two operations must be performed explicitly.
First you define a thread. And if you never call join() or detach() before calling the thread destructor, the program will abort.
As follows, calling a thread destructor without first calling join (to wait for it to finish) or detach is guarenteed to immediately call std::terminate and end the program.
Either implicitly detaching or joining a joinable() thread in its
destructor could result in difficult to debug correctness (for detach)
or performance (for join) bugs encountered only when an exception is
raised. Thus the programmer must ensure that the destructor is never
executed while the thread is still joinable.
As long as your program die, then without detach or join of the thread, this error will occur. Without detaching and joining the thread, you should give endless loop after creating thread.
int main(){
std::thread t(thread,1);
while(1){}
//t.detach();
return 0;}
It is also interesting that, after sleeping or looping, thread can be detach or join. Also with this way you do not get this error.
Below example also shows that, third thread can not done his job before main die. But this error can not happen also, as long as you detach somewhere in the code.
Third thread sleep for 8 seconds but main will die in 5 seconds.
void thread(int n) {std::this_thread::sleep_for (std::chrono::seconds(n));}
int main() {
std::cout << "Start main\n";
std::thread t(thread,1);
std::thread t2(thread,3);
std::thread t3(thread,8);
sleep(5);
t.detach();
t2.detach();
t3.detach();
return 0;}
yes, the thread must be join(). when the main exit

main doesn't continue after pthread

Im using Ubuntu 10.10, Code::Blocks with GCC 4.2.
I have written a code like that:
#include <iostream>
#include <stdlib.h>
#include <pthread.h>
using namespace std;
void *thread1proc(void* param){
while(true)
cout << "1";
return 0;
}
int main(){
pthread_t thread1;
pthread_create(&thread1,NULL,thread1proc,NULL);
pthread_join(thread1,NULL);
cout << "hello";
}
Main starts, creates the thread. But what is weird (for me) is main doesn't continue running. I expect to see "hello" message on screen and end of the program. Because in Windows, in Delphi it worked for me like that. If "main" is also a thread, why doesn't it continue running? Is it about POSIX threading?
Thank you.
pthread_join will block until thread1 completes (calling pthread_exit or returning), which (as it has an infinite loop) it never will do.
It stops because you call pthread_join and the thread you are joining "to" has an infinite loop.
From that link:
The pthread_join() function suspends
execution of the calling thread until
the target thread terminates, unless
the target thread has already
terminated.