I picked up the following demo off the web from https://computing.llnl.gov/tutorials/pthreads/

    #include &lt;pthread.h&gt;
    #include &lt;stdio.h&gt;
    #define NUM_THREADS     5

    void *PrintHello(void *threadid)
    {
       long tid;
       tid = (long)threadid;
       printf(&quot;Hello World! It&#39;s me, thread #%ld!\n&quot;, tid);
       pthread_exit(NULL);
    }

    int main (int argc, char *argv[])
    {
       pthread_t threads[NUM_THREADS];
       int rc;
       long t;
       for(t=0; t&lt;NUM_THREADS; t++){
          printf(&quot;In main: creating thread %ld\n&quot;, t);
          rc = pthread_create(&amp;threads[t], NULL, PrintHello, (void *)t);
          if (rc){
             printf(&quot;ERROR; return code from pthread_create() is %d\n&quot;, rc);
             exit(-1);
          }
       }
       pthread_exit(NULL);
    }

But when I compile it on my machine (running Ubuntu Linux 9.04) I get the following error:

    corey@ubuntu:~/demo$ gcc -o term term.c
    term.c: In function ‘main’:
    term.c:23: warning: incompatible implicit declaration of built-in function ‘exit’
    /tmp/cc8BMzwx.o: In function `main&#39;:
    term.c:(.text+0x82): undefined reference to `pthread_create&#39;
    collect2: ld returned 1 exit status

This doesn&#39;t make any sense to me, because the header includes `pthread.h`, which should have the `pthread_create` function. Any ideas what&#39;s going wrong?


Undefined reference to pthread_create in Linux

Can somebody please explain with examples (of code) what is the difference between **deadlock** and **livelock**?

What&#39;s the difference between deadlock and livelock?

I&#39;m running `RHEL 5.1` and use `gcc`.

How I tell `cmake` to add `-pthread` to compilation and linking?

cmake and libpthread

I’m reading up on `pthread.h`; the condition variable related functions (like `pthread_cond_wait(3)`) require a mutex as an argument. Why? As far as I can tell, I’m going to be creating a mutex *just* to use as that argument? What is that mutex supposed to do?

Why do pthreads’ condition variable functions require a mutex?

Why should I prefer one or another in practice?
What are technical differences except that `std::thread` is a class?

C++11 std::threads vs posix threads

All the functions mentioned in this block are library functions. How can I rectify this memory leak? 

It is listed under the &quot;**Still reachable**&quot; category. (There are 4 more, which are very similar, but of varying sizes)

     630 bytes in 1 blocks are still reachable in loss record 5 of 5
        at 0x4004F1B: calloc (vg_replace_malloc.c:418)
        by 0x931CD2: _dl_new_object (dl-object.c:52)
        by 0x92DD36: _dl_map_object_from_fd (dl-load.c:972)
        by 0x92EFB6: _dl_map_object (dl-load.c:2251)
        by 0x939F1B: dl_open_worker (dl-open.c:255)
        by 0x935965: _dl_catch_error (dl-error.c:178)
        by 0x9399C5: _dl_open (dl-open.c:584)
        by 0xA64E31: do_dlopen (dl-libc.c:86)
        by 0x935965: _dl_catch_error (dl-error.c:178)
        by 0xA64FF4: __libc_dlopen_mode (dl-libc.c:47)
        by 0xAE6086: pthread_cancel_init (unwind-forcedunwind.c:53)
        by 0xAE61FC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)

**Catch:** Once I ran my program, it gave no memory leaks, but it had one additional line in the Valgrind output, which wasn&#39;t present before:

&gt; Discarding syms at 0x5296fa0-0x52af438
&gt; in /lib/libgcc_s-4.4.4-20100630.so.1
&gt; due to munmap()

If the leak can&#39;t be rectified, can someone atleast explain why the munmap() line causes Valgrind to report 0 &quot;still reachable&quot; leaks?

**Edit:**

Here&#39;s a minimal test sample:

    #include &lt;stdio.h&gt;
    #include &lt;stdlib.h&gt;
    #include &lt;pthread.h&gt;
    
    void *runner(void *param) {
    	/* some operations ... */
    	pthread_exit(NULL);
    }
    
    int n;
    
    int main(void) {
    	
        int i;
    	pthread_t *threadIdArray;
    	
    	n=10; /* for example */
    
    	threadIdArray = malloc((n+n-1)*sizeof(pthread_t));  
    		
    	for(i=0;i&lt;(n+n-1);i++) {
    		if( pthread_create(&amp;threadIdArray[i],NULL,runner,NULL) != 0 ) {
    			printf(&quot;Couldn&#39;t create thread %d\n&quot;,i);
    			exit(1);
    		}
    	}
    	
    	
    	for(i=0;i&lt;(n+n-1);i++) {
    		pthread_join(threadIdArray[i],NULL);
    	}
    	
    	free(threadIdArray);
    	
    	return(0);
    }

Run with:

    valgrind -v --leak-check=full --show-reachable=yes ./a.out

 

Still Reachable Leak detected by Valgrind

I&#39;m installing mingw-w64 on Windows and there are two options: win32 threads and posix threads. I know what is the difference between win32 threads and pthreads but I don&#39;t understand what is the difference between these two options. I doubt that if I will choose posix threads it will prevent me from calling WinAPI functions like CreateThread.

It seems that this option specify which threading API will be used by some program or library, but by what? By GCC, libstdc++ or by something else?

I found this:
https://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo

&gt; In short, for this version of mingw, the threads-posix release will use the posix API and allow the use of std::thread, and the threads-win32 will use the win32 API, and disable the std::thread part of the standard.

Ok, if I will select win32 threads then std::thread will be unavailable but win32 threads will still be used. But used by what?

mingw-w64 threads: posix vs win32

In various multi threaded C and C++ projects I&#39;ve seen the `-pthread` flag applied to both the compiling and linking stage while others don&#39;t use it at all and just pass `-lpthread` to the linking stage.

Is there any danger not compiling and linking with the `-pthread` flag - i.e. what does `-pthread` actually do ? I&#39;m primarily interested in Linux platforms.

Significance of -pthread flag when compiling

To quote the man page:

&gt; When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return.

So, `pthread_cond_wait` can return even if you haven&#39;t signaled it. At first glance at least, that seems pretty atrocious. It would be like a function which randomly returned the wrong value or randomly returned before it actually reached a proper return statement. It seems like a major bug. But the fact that they chose to document this in the man page rather than fix it would seem to indicate that there is a legitimate reason why `pthread_cond_wait` ends up waking up spuriously. Presumably, there&#39;s something intrinsic about how it works that makes it so that that can&#39;t be helped. The question is what.

_Why_ does `pthread_cond_wait` return spuriously? Why can&#39;t it guarantee that it&#39;s only going to wake up when it&#39;s been properly signaled? Can anyone explain the reason for its spurious behavior?

Why does pthread_cond_wait have spurious wakeups?

What is the difference between `gcc -pthread` and `gcc -lpthread` which is used while compiling multithreaded programs?

Difference between -pthread and -lpthread while compiling

I always get confused. Would someone explain what [Reentrant][1] means in different contexts? And why would you want to use reentrant vs. non-reentrant?

Say pthread (posix) locking primitives, are they re-entrant or not? What pitfalls should be avoided when using them?

Is mutex re-entrant?

  [1]: http://en.wikipedia.org/wiki/Reentrant_(subroutine)

What is the Re-entrant lock and concept in general?

I need to pass multiple arguments to a function that I would like to call on a separate thread. I&#39;ve [read][1] that the typical way to do this is to define a struct, pass the function a pointer to that, and dereference it for the arguments. However, I am unable to get this to work:

    #include &lt;stdio.h&gt;
    #include &lt;pthread.h&gt;
    
    struct arg_struct {
    	int arg1;
    	int arg2;
    };
    
    void *print_the_arguments(void *arguments)
    {
    	struct arg_struct *args = (struct arg_struct *)args;
    	printf(&quot;%d\n&quot;, args -&gt; arg1);
    	printf(&quot;%d\n&quot;, args -&gt; arg2);
    	pthread_exit(NULL);
    	return NULL;
    }
    
    int main()
    {
    	pthread_t some_thread;
    	struct arg_struct args;
    	args.arg1 = 5;
    	args.arg2 = 7;
    
    	if (pthread_create(&amp;some_thread, NULL, &amp;print_the_arguments, (void *)&amp;args) != 0) {
    		printf(&quot;Uh-oh!\n&quot;);
    		return -1;
    	}
    
    	return pthread_join(some_thread, NULL); /* Wait until thread is finished */
    }

The output for this should be:

    5
    7

But when I run it I actually get:

    141921115
    -1947974263

Anyone know what I&#39;m doing wrong?

  [1]: https://computing.llnl.gov/tutorials/pthreads/#PassingArguments

Multiple arguments to function called by pthread_create()?

In a Linux C program, how do I print the thread id of a thread created by the pthread library? For example like how we can get pid of a process by `getpid()`.

How to get thread id of a pthread in linux c program?

Is there any difference between 

    pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

**Or**

    pthread_mutex_t lock;
    pthread_mutex_init ( &amp;lock, NULL);

Am I safe enough if I use only the first method ?

**NOTE:** My question mostly refers to very small programs where at the most what I&#39;ll do is connect several clients to a server and resolve their inquiries with worker threads.

PTHREAD_MUTEX_INITIALIZER vs pthread_mutex_init ( &amp;mutex, param)

For something simple like a counter if multiple threads will be increasing the number. I read that mutex locks can decrease efficiency since the threads have to wait. So, to me, an atomic counter would be the most efficient, but I read that internally it is basically a lock? So I guess I&#39;m confused how either could be more efficient than the other. 

Which is more efficient, basic mutex lock or atomic integer?

Let&#39;s say I have a class such as

    class c { 
        // ...
        void *print(void *){ cout &lt;&lt; &quot;Hello&quot;; }
    }

And then I have a vector of c

    vector&lt;c&gt; classes; pthread_t t1;
    classes.push_back(c());
    classes.push_back(c());

Now, I want to create a thread on `c.print();`

And the following is giving me the problem below: `pthread_create(&amp;t1, NULL, &amp;c[0].print, NULL);`

&gt; Error Ouput: cannot convert ‘void* (tree_item::*)(void*)’ to ‘void*
&gt; (*)(void*)’  for argument ‘3’ to ‘int pthread_create(pthread_t*, const
&gt; pthread_attr_t*, void* (*)(void*), void*)’

pthread function from a class

I read somewhere that we should lock the **mutex** before calling **pthread_cond_signal** and unlock the mutex after calling it:

&gt; The pthread_cond_signal() routine is
&gt; used to signal (or wake up) another
&gt; thread which is waiting on the
&gt; condition variable. It should be
&gt; called after mutex is locked, and must
&gt; unlock mutex in order for
&gt; pthread_cond_wait() routine to
&gt; complete.

My question is: isn&#39;t it OK to call **pthread_cond_signal** or **pthread_cond_broadcast** methods without locking the mutex?

Calling pthread_cond_signal without locking mutex

I&#39;ve been trying to understand the intricacies of how POSIX threads and POSIX signals interact. In particular, I&#39;m interested in:

* What&#39;s the best way to control which thread a signal is delivered to (assuming it isn&#39;t fatal in the first place)?
* What is the best way to tell another thread (that might actually be busy) that the signal has arrived? (I already know that it&#39;s a bad idea to be using pthread condition variables from a signal handler.)
* How can I safely handle passing the information that a signal has occurred to other threads? Does this need to happen in the signal handler? (I do not in general want to kill the other threads; I need a far subtler approach.)

For reference about why I want this, I&#39;m researching how to convert the [TclX](http://sourceforge.net/projects/tclx/) package to support threads, or to split it up and at least make some useful parts support threads. Signals are one of those parts that is of particular interest.

POSIX threads and signals

Firstly, I use pthread library to write multithreading C programs. Threads always hung by their waited mutexes. When I use the strace utility to find a thread in the `FUTEX_WAIT` status, I want to know which thread holds that mutex at that time. But I don&#39;t know how I could I do it. Are there any utilities that could do that?  

Someone told me the Java virtual machine supports this, so I want to know whether Linux support this feature.

Is it possible to determine the thread holding a mutex?

What is the difference between semaphores and mutex provided by pthread library ?

pthreads mutex vs semaphore

The usual pattern for a singleton class is something like

    static Foo &amp;getInst()
    {
      static Foo *inst = NULL;
      if(inst == NULL)
        inst = new Foo(...);
      return *inst;    
    }
However, it&#39;s my understanding that this solution is not thread-safe, since 1) Foo&#39;s constructor might be called more than once (which may or may not matter) and 2) inst may not be fully constructed before it is returned to a different thread.

One solution is to wrap a mutex around the whole method, but then I&#39;m paying for synchronization overhead long after I actually need it. An alternative is something like

    static Foo &amp;getInst()
    {
      static Foo *inst = NULL;
      if(inst == NULL)
      {
        pthread_mutex_lock(&amp;mutex);
        if(inst == NULL)
          inst = new Foo(...);
        pthread_mutex_unlock(&amp;mutex);
      }
      return *inst;    
    }
Is this the right way to do it, or are there any pitfalls I should be aware of? For instance, are there any static initialization order problems that might occur, i.e. is inst always guaranteed to be NULL the first time getInst is called?

efficient thread-safe singleton in C++

I&#39;m creating a multi-threaded application in C using Linux.

I&#39;m unsure whether I should use the POSIX thread API or the OpenMP API.

What are the pros &amp; cons of using either?

**Edit:**

Could someone clarify whether both APIs create **kernel-level** or **user-level** threads?

Pthreads vs. OpenMP

I&#39;am new to C and would like to play with threads a bit. I would like to return some value from a thread using `pthread_exit()`

My code is as follows:

    #include &lt;pthread.h&gt;
    #include &lt;stdio.h&gt;
    
    void *myThread()
    {
       int ret = 42;
       pthread_exit(&amp;ret);
    }
    
    int main()
    {
       pthread_t tid;
       void *status;
     
       pthread_create(&amp;tid, NULL, myThread, NULL);
       pthread_join(tid, &amp;status);
    
       printf(&quot;%d\n&quot;,*(int*)status);   
     
       return 0;
    }

I would expect the program output `&quot;42\n&quot;` but it outputs a random number. How can I print the returned value?

It seems to be a problem that I am returning a pointer to a local variable. What is the best practice of returning/storing variables of multiple threads? A global hash table?

How to return a value from pthread threads in C?

I am using pthread in Linux. I would like to increase the thread priority by setting the parameters `sched_param.priority`. However, I could not find much info from the net regarding the range of the thread priority I could set, or about the description of the thread priority.

Also, I would like to know about the relative thread priority as I would not want to set the thread priority to be too high and resulting the OS to halt. Could someone help me with this?

How to increase thread priority in pthreads?

Can someone please explain the difference between preemptive Threading model and Non Preemptive threading model?  
 
As per my understanding:  

* ***Non Preemptive threading model:***  Once a thread is started it cannot be stopped or the control cannot be transferred to other threads until the thread has completed its task.  
* ***Preemptive Threading Model:*** The runtime is allowed to step in and hand control from one thread to another at any time. Higher priority threads are given precedence over Lower priority threads.   

Can someone please:

 1. Explain if the understanding is correct.
 2. Explain the advantages and disadvantages of both models.
 3. An example of when to use what will be really helpful.
 4. If i create a thread in Linux (system v or Pthread) without mentioning any options(are there any??) by default the threading model used is preemptive threading model?



Preemptive threads Vs Non Preemptive threads

I am working on some code which uses the pthread and semaphore libraries. The `sem_init` function works fine on my Ubuntu machine, but on OS X the `sem_init` function has absolutely no effect. Is there something wrong with the library or is there a different way of doing it? This is the code I am using to test.

    sem_t sem1;
    sem_t sem2;
    sem_t sem3;
    sem_t sem4;
    sem_t sem5;
    sem_t sem6;

    sem_init(&amp;sem1, 1, 1);
    sem_init(&amp;sem2, 1, 2);
    sem_init(&amp;sem3, 1, 3);
    sem_init(&amp;sem4, 1, 4);
    sem_init(&amp;sem5, 1, 5);
    sem_init(&amp;sem6, 1, 6);

The values appear to be random numbers, and they do not change after the `sem_init` call.

sem_init on OS X

If I try to compile a program with

    #include &lt;pthread.h&gt;
in it, I get the error:

    pthread.h: No such file or directory

Is it possible to get this to compile in a Windows environment?

I am using Vista with the latest MinGW.

I do not want to use the Microsoft Windows Services for UNIX Version 3.5 as I will have to move this to a Unix environment.

Can I get Unix&#39;s pthread.h to compile in Windows?

I&#39;ve been using the `pthread` library for creating &amp; joining threads in C.

1. When should I create a thread as detached, right from the outset? Does it offer any performance advantage vs. a joinable thread?

2. Is it legal to not do a `pthread_join()` on a joinable (by default) thread? Or should such a thread always use the `detach()` function before `pthread_exit()`ing?

Detached vs. Joinable POSIX threads

Searched, but don&#39;t come across a satisfying answer. 

I know there&#39;s no a portable way to print a pthread_t. 

How do you do it in your app?


**Update:** 

Actually I don&#39;t need pthread_t, but some small numeric id, identifying in debug message different threads. 

On my system (64 bit RHEL 5.3) it&#39;s defined as unsigned long int, so it&#39;s big number and just printing it eats a valuable place in debug line. How does **gdb assign** short tids?

How to print pthread_t

Is there any way of setting the name of a thread in Linux?

My main purpose is it would be helpful while debugging, and also nice if that name was exposed through e.g. `/proc/$PID/task/$TID/...`


How to set the name of a thread in Linux pthreads?

In my destructor I want to destroy a thread cleanly.

My goal is to wait for a thread to finish executing and THEN destroy the thread.

The only thing I found about querying the state of a pthread is [pthread_attr_setdetachstate][1] but this only tells you if your thread is:

 - PTHREAD_CREATE_DETACHED 
 - PTHREAD_CREATE_JOINABLE

Both of those have nothing to do with whether the thread is still running or not.

**How do you query a pthread to see if it is still running?**

  [1]: https://computing.llnl.gov/tutorials/pthreads/man/pthread_attr_getdetachstate.txt

How do you query a pthread to see if it is still running?

The title might not be clear enough because I don&#39;t know how to define my questions actually.

I understand Pthread is a thread library meeting POSIX standard (about POSIX, see wikipedia: http://en.wikipedia.org/wiki/Posix). It is available in Unix-like OS.

About thread, I read that there are three different models:

**User level thread:** the kernel does not know it. User himself creates/implements/destroy threads.

**Kernel level thread:** kernel directly supports multiple threads of control in a process.

**Light weight process(LWP):** scheduled by kernel but can be bounded with user threads.

Did you see my confusion? When I call `pthread_create()` to create a thread, did I create a user level thread? I guess so. So can I say, Pthread offers a user level solution for threads? It can not manipulate kernel/LWP?

Is Pthread library actually a user thread solution?

I am new to pthreads, and I am trying to understand it. I saw some examples like the following. 

I could see that the `main()` is blocked by the API `pthread_exit()`, and I have seen examples where the main function is blocked by the API `pthread_join()`. I am not able to understand when to use what? 

I am referring to the following site - [https://computing.llnl.gov/tutorials/pthreads/][1]. I am not able to get the concept of when to use `pthread_join()` and when to use `pthread_exit()`. 

Can somebody please explain? Also, a good tutorial link for pthreads will be appreciated.

    #include &lt;pthread.h&gt;
    #include &lt;stdio.h&gt;
    #define NUM_THREADS     5
    
    void *PrintHello(void *threadid)
    {
       long tid;
       tid = (long)threadid;
       printf(&quot;Hello World! It&#39;s me, thread #%ld!\n&quot;, tid);
       pthread_exit(NULL);
    }
    
    int main (int argc, char *argv[])
    {
       pthread_t threads[NUM_THREADS];
       int rc;
       long t;
       for(t=0; t&lt;NUM_THREADS; t++){
          printf(&quot;In main: creating thread %ld\n&quot;, t);
          rc = pthread_create(&amp;threads[t], NULL, PrintHello, (void *)t);
          if (rc){
             printf(&quot;ERROR; return code from pthread_create() is %d\n&quot;, rc);
             exit(-1);
          }
       }
    
       /* Last thing that main() should do */
       pthread_exit(NULL);


  [1]: https://computing.llnl.gov/tutorials/pthreads/


Realized one more thing i.e.  

    pthread_cancel(thread);
    pthread_join(thread, NULL);

Sometimes, you want to cancel the thread while it is executing.
You could do this using pthread_cancel(thread);.
However, remember that you need to enable pthread cancel support.
Also, a clean up code upon cancellation.

    thread_cleanup_push(my_thread_cleanup_handler, resources);
    pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, 0);

    static void my_thread_cleanup_handler(void *arg)
    {
      // free
      // close, fclose
    }



When to use pthread_exit() and when to use pthread_join() in Linux?

I just reviewed some really terrible code - code that sends messages on a serial port by creating a new thread to package and assemble the message in a new thread for every single message sent. Yes, for every message a pthread is created, bits are properly set up, then the thread terminates. I haven&#39;t a clue why anyone would do such a thing, but it raises the question - how much overhead is there when actually creating a thread?  

How much overhead is there when creating a thread?

As [**Wikipedia states**][1]:

&gt; Green threads emulate multi-threaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

Python&#39;s threads are implemented as `pthreads (kernel threads)`,
and because of the global interpreter lock (GIL), a Python process only runs one thread at a time.

[**QUESTION**]
But in the case of `Green-threads` (or so-called greenlet or tasklets),

&gt;  1. Does the `GIL` affect them? Can there be more than one greenlet
&gt;     running at a time?
&gt;  2. What are the pitfalls of using greenlets or tasklets?
&gt;  3. If I use greenlets, how many of them can a process can handle? (I am wondering because in a single process you can open threads up to
&gt; *ulimit*(*-s*, *-v*) set in your *ix system.)

I need a little insight, and it would help if someone could share their experience, or guide me to the right path.

  [1]: http://en.wikipedia.org/wiki/Green_threads


Green-threads and thread in Python

I would like to call pthread_join for a given thread id, but only if that thread has been started. The safe solution might be to add a variable to track which thread where started or not. However, I wonder if checking pthread_t variables is possible, something like the following code.

    pthread_t thr1 = some_invalid_value; //0 ?
    pthread_t thr2 = some_invalid_value;
    
    /* thread 1 and 2 are strated or not depending on various condition */
    ....
    
    /* cleanup */
    if(thr1 != some_invalid_value)
        pthread_join(&amp;thr1);
    
    if(thr2 != some_invalid_value)
        pthread_join(&amp;thr2);


Where some_invalid_value could be 0, or an implementation dependant &#39;PTHREAD_INVALID_ID&#39; macro

PS :
My assumption is that pthread_t types are comparable and assignable, assumption based on [&lt;sys/type.h&gt;][1]

PPS :
I wanted to do this, because I thought calling pthread_join on invalid thread id was undefinde behaviour. It is not. However, joining a previously joined thread IS undefined behaviour. Now let&#39;s assume the above &quot;function&quot; is called repeatedly.
Unconditionnally calling pthread_join and checking the result might result in calling pthread_join on a previously joined thread.

  [1]: http://pubs.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html

Is there an invalid pthread_t id?

I am a bit confused on how to declare a recursive mutex using pthread.
What I try to do is have only one thread at a time be able to run a piece of code(including functions) but after scepticism I figured out that the use of mutexes would not work and that instead I should use recursive mutexes. Here is my code:

    pthread_mutex_lock(&amp;mutex);                   // LOCK
    
    item = queue_peek(queue);                     // get last item in queue
    item_buff=item;                               // save item to a buffer
    queue_removelast(queue);                      // remove last item from queue
    
    pthread_mutex_unlock(&amp;mutex);                 // UNLOCK

So what I try to do is just read/remove from the queue serially.

The thing is that there isn&#39;t any example out there on how to declare recursive mutexes. Or there maybe a few but they don&#39;t compile for me.

C: How do you declare a recursive mutex with POSIX threads?

I&#39;m learning pthread and wait conditions. As far as I can tell a typical waiting thread is like this:

    pthread_mutex_lock(&amp;m);
    while(!condition)
         pthread_cond_wait(&amp;cond, &amp;m);
    // Thread stuff here
    pthread_mutex_unlock(&amp;m);

What I can&#39;t understand is why the line `while(!condition)` is necessary even if I use `pthread_cond_signal()` to wake up the thread.

I can understand that if I use `pthread_cond_broadcast()` I need to test condition, because I wake up *all* waiting threads and one of them can make the condition false again before unlocking the mutex (and thus transferring execution to another waked up thread which should not execute at that point).
But if I use `pthread_cond_signal()` I wake up just *one* thread so the condition must be true. So the code could look like this:

    pthread_mutex_lock(&amp;m);
    pthread_cond_wait(&amp;cond, &amp;m);
    // Thread stuff here
    pthread_mutex_unlock(&amp;m);

I read something about spurious signals that may happen. Is this (and only this) the reason? Why should I have spurious singnals? Or there is something else I don&#39;t get?

I assume the signal code is like this:

    pthread_mutex_lock(&amp;m);
    condition = true;
    pthread_cond_signal(&amp;cond); // Should wake up *one* thread
    pthread_mutex_unlock(&amp;m);



Why is a while loop needed around pthread wait conditions?

Why are POSIX mutexes considered heavier or slower than futexes? Where is the overhead coming from in the pthread mutex type? I&#39;ve heard that pthread mutexes are based on futexes, and when uncontested, do not make any calls into the kernel.  It seems then that a pthread mutex is merely a &quot;wrapper&quot; around a futex.

Is the overhead simply in the function-wrapper call and the need for the mutex function to &quot;setup&quot; the futex (i.e., basically the setup of the stack for the pthread mutex function call)?  Or are there some extra memory barrier steps taking place with the pthread mutex?

All Pthreads Solutions on Gang of Coders

Total of 39 Pthreads Solutions