As TazMainiac said, scheduler-locking is useful for single stepping, but the “mode” must be set to “step”. set scheduler-locking step You can refer the link provided by TazMainiac which mentions the same: http://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_39.html The step mode optimizes for single-stepping. It stops other threads from “seizing the prompt” by preempting the current thread while you are … Read more
The short answer is that a spinlock can be better when you plan to hold the lock for an extremely short interval (for example to do nothing but increment a counter), and contention is expected to be rare, but the operation is occurring often enough to be a potential performance bottleneck. The advantages of a … Read more
In pthread_exit, ret is an input parameter. You are simply passing the address of a variable to the function. In pthread_join, ret is an output parameter. You get back a value from the function. Such value can, for example, be set to NULL. Long explanation: In pthread_join, you get back the address passed to pthread_exit … Read more
Initially I come from a posix threads background, and was wondering how does one setup the stack size of the std::thread prior to construction, as I can’t seem to find any references to performing such a task. You can’t. std::thread doesn’t support this because std::thread is standardized, and C++ does not require that a machine … Read more
It basically boils down to what level of control you want over your parallelization. OpenMP is great if all you want to do is add a few #pragma statements and have a parallel version of your code quite quickly. If you want to do really interesting things with MIMD coding or complex queueing, you can … Read more
A condition variable allows a thread to be signaled when something of interest to that thread occurs. By itself, a mutex doesn’t do this. If you just need mutual exclusion, then condition variables don’t do anything for you. However, if you need to know when something happens, then condition variables can help. For example, if … Read more
Rock solid for 4 days straight. I’m declaring victory on this one. The answer is “stupid user error” (see comments above). A mutex should only be unlocked by the thread that locked it. Thanks for bearing with me.
The following minimal test case exhibits the behaviour you describe: #include <pthread.h> #include <unistd.h> void *app1(void *x) { sleep(1); pthread_exit(0); } int main() { pthread_t t1; pthread_create(&t1, NULL, app1, NULL); pthread_join(t1, NULL); return 0; } valgrind –leak-check=full –show-reachable=yes shows 5 blocks allocated from functions called by pthread_exit() that is unfreed but still reachable at process … Read more
Building on szx’s answer (so give him the credit), here’s how it would work in your for loop: void *foo(void *i) { int a = *((int *) i); free(i); } int main() { pthread_t thread; for ( int i = 0; i < 10; ++1 ) { int *arg = malloc(sizeof(*arg)); if ( arg == … Read more
First store the thread id pthread_create(&thr, …) then later call pthread_cancel(thr) However, this not a recommended programming practice! It’s better to use an inter-thread communication mechanism like semaphores or messages to communicate to the thread that it should stop execution. Note that pthread_kill(…) does not actually terminate the receiving thread, but instead delivers a signal … Read more