POSIX threads explained, part 1

Beginning threads

Here's a simple example program that uses POSIX threads:

#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>

void *thread_function(void *arg) {
  int i;
  for ( i=0; i<20; i++ ) {
    printf("Thread says hi!\n");
    sleep(1);
  }
  return NULL;
}

int main(void) {

  pthread_t mythread;
  
  if ( pthread_create( &mythread, NULL, thread_function, NULL) ) {
    printf("error creating thread.");
    abort();
  }

  if ( pthread_join ( mythread, NULL ) ) {
    printf("error joining thread.");
    abort();
  }

  exit(0);

}

To compile this program, simply save this program as thread1.c, and type:

1.1 xml/htdocs/doc/en/articles/l-posix2.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/l-posix2.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/l-posix2.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo Index: l-posix2.xml =================================================================== POSIX threads explained, part 2 Daniel Robbins Łukasz Damentko POSIX threads are a great way to increase the responsiveness and performance of your code. In this second article of a three-part series, Daniel Robbins shows you how to protect the integrity of shared data structures in your threaded code by using nifty little things called mutexes. 1.0 2005-07-27 The little things called mutexes

Mutex me! The original version of this article was published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux Documentation team.

In my previous article, I talked about threaded code that did unusual and unexpected things. Two threads each incremented a global variable twenty times. The variable was supposed to end up with a value of 40, but ended up with a value of 21 instead. What happened? The problem occurred because one thread repeatedly "cancelled out" the increment performed by the other thread. Let's take a look at some corrected code that uses a mutex to solve the problem:

#include <pthread.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int myglobal;
pthread_mutex_t mymutex=PTHREAD_MUTEX_INITIALIZER;

void *thread_function(void *arg) {
  int i,j;
  for ( i=0; i<20; i++ ) {
    pthread_mutex_lock(&mymutex);
    j=myglobal;
    j=j+1;
    printf(".");
    fflush(stdout);
   sleep(1);
    myglobal=j;
    pthread_mutex_unlock(&mymutex);
  }
  return NULL;
}

int main(void) {

  pthread_t mythread;
  int i;

  if ( pthread_create( &mythread, NULL, thread_function, NULL) ) {
    printf("error creating thread.");
    bort();
  }

  for ( i=0; i<20; i++) {
    pthread_mutex_lock(&mymutex);
    myglobal=myglobal+1;
    pthread_mutex_unlock(&mymutex);
    printf("o");
    fflush(stdout);
    sleep(1);
  }

  if ( pthread_join ( mythread, NULL ) ) {
    printf("error joining thread.");
    abort();
  }

  printf("\nmyglobal equals %d\n",myglobal);

  exit(0);

}

Comprehension time

If you compare this code to the version in my previous article, you'll notice the addition of the calls pthread_mutex_lock() and pthread_mutex_unlock(). These calls perform a much-needed function in threaded programs. They provide a means of mutual exclusion (hence the name). No two threads can have the same mutex locked at the same time.

This is how mutexes work. If thread "a" tries to lock a mutex while thread "b" has the same mutex locked, thread "a" goes to sleep. As soon as thread "b" releases the mutex (via a pthread_mutex_unlock() call), thread "a" will be able to lock the mutex (in other words, it will return from the pthread_mutex_lock() call with the mutex locked). Likewise, if thread "c" tries to lock the mutex while thread "a" is holding it, thread "c" will also be put to sleep temporarily. All threads that go to sleep from calling pthread_mutex_lock() on an already-locked mutex will "queue up" for access to that mutex.

pthread_mutex_lock() and pthread_mutex_unlock() are normally used to protect data structures. That is, you make sure that only one thread at a time can access a certain data structure by locking and unlocking it. As you may have guessed, the POSIX threads library will grant a lock without having put the thread to sleep at all if a thread tries to lock an unlocked mutex.

The thread in this image that has the mutex locked gets to access the complex data structure without worrying about having other threads mess with it at the same time. The data structure is in effect "frozen" until the mutex is unlocked. It's as if the pthread_mutex_lock() and pthread_mutex_unlock() calls are "under construction" signs that surround a particular piece of shared data that's being modified or read. The calls act as a warning to other threads to go to sleep and wait their turn for the mutex lock. Of course this is only true if your surround every read and write to a particular data structure with calls to pthread_mutex_lock() and pthread_mutex_unlock().

Why mutex at all?

Sounds interesting, but why exactly do we want to put our threads to sleep? After all, isn't the main advantage of threads their ability to work independently and in many cases simultaneously? Yes, that's completely true. However, every non-trivial threads program will require at least some use of mutexes. Let's refer to our example program again to understand why.

If you take a look at thread_function(), you'll notice that the mutex is locked at the beginning of the loop and released at the very end. In this example program, mymutex is used to protect the value of myglobal. If you look carefully at thread_function() you'll notice that the increment code copies myglobal to a local variable, increments the local variable, sleeps for one second, and only then copies the local value back to myglobal. Without the mutex, thread_function() will overwrite the incremented value when it wakes up if our main thread increments myglobal during thread_function()'s one-second nap. Using a mutex ensures that this doesn't happen. (In case you're wondering, I added the one-second delay to trigger a flawed result. There is no real reason for thread_function() to go to sleep for one second before writing the local value back to myglobal.) Our new program using mutex produces the desired result:

$ ./thread3
o..o..o.o..o..o.o.o.o.o..o..o..o.ooooooo
myglobal equals 40

To further explore this extremely important concept, let's take a look at the increment code from our program:

thread_function() increment code: 
   j=myglobal;



1.1                  xml/htdocs/doc/en/articles/l-posix3.xml

file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/l-posix3.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/l-posix3.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo

Index: l-posix3.xml
===================================================================





POSIX threads explained, part 3


  Daniel Robbins


  Łukasz Damentko



In this article, the last of a three-part series on POSIX threads, Daniel takes
a good look at how to use condition variables. Condition variables are POSIX
thread structures that allow you to "wake up" threads when certain conditions
are met. You can think of them as a thread-safe form of signalling. Daniel wraps
up the article by using all that you've learned so far to implement a
multi-threaded work crew application.




1.0
2005-07-28


Improve efficiency with condition variables

Condition variables explained



The original version of this article was published on IBM developerWorks, and is
property of Westtech Information Services. This document is an updated version
of the original article, and contains various improvements made by the Gentoo
Linux Documentation team.



I ended my previous article by
describing a particular dilemma how does a thread deal with a situation where
it is waiting for a specific condition to become true? It could repeatedly lock
and unlock a mutex, each time checking a shared data structure for a certain
value. But this is a waste of time and resources, and this form of busy polling
is extremely inefficient. The best way to do this is to use the
pthread_cond_wait() call to wait on a particular condition to become true.



It's important to understand what pthread_cond_wait() does -- it's the heart of
the POSIX threads signalling system, and also the hardest part to understand.



First, let's consider a scenario where a thread has locked a mutex, in order to
take a look at a linked list, and the list happens to be empty. This particular
thread can't do anything -- it's designed to remove a node from the list, and
there are no nodes available. So, this is what it does.



While still holding the mutex lock, our thread will call
pthread_cond_wait(&mycond,&mymutex). The pthread_cond_wait() call is
rather complex, so we'll step through each of its operations one at a time.



The first thing pthread_cond_wait() does is simultaneously unlock the mutex
mymutex (so that other threads can modify the linked list) and wait on the
condition mycond (so that pthread_cond_wait() will wake up when it is
"signalled" by another thread). Now that the mutex is unlocked, other threads
can access and modify the linked list, possibly adding items. 



At this point, the pthread_cond_wait() call has not yet returned. Unlocking the
mutex happens immediately, but waiting on the condition mycond is normally a
blocking operation, meaning that our thread will go to sleep, consuming no CPU
cycles until it is woken up. This is exactly what we want to happen. Our thread
is sleeping, waiting for a particular condition to become true, without
performing any kind of busy polling that would waste CPU time. From our thread's
perspective, it's simply waiting for the pthread_cond_wait() call to return. 



Now, to continue the explanation, let's say that another thread (call it "thread
2") locks mymutex and adds an item to our linked list. Immediately after
unlocking the mutex, thread 2 calls the function
pthread_cond_broadcast(&mycond). By doing so, thread 2 will cause all
threads waiting on the mycond condition variable to immediately wake up. This
means that our first thread (which is in the middle of a pthread_cond_wait()
call) will now wake up.



Now, let's take a look at what happens to our first thread. After thread 2
called pthread_cond_broadcast(&mymutex) you might think that thread 1's
pthread_cond_wait() will immediately return. Not so! Instead,
pthread_cond_wait() will perform one last operation: relock mymutex. Once
pthread_cond_wait() has the lock, it will then return and allow thread 1 to
continue execution. At that point, it can immediately check the list for any
interesting changes.





Stop and review!



/* queue.h
** Copyright 2000 Daniel Robbins, Gentoo Technologies, Inc.
** Author: Daniel Robbins
** Date: 16 Jun 2000
*/
typedef struct node {
  struct node *next;
} node;
typedef struct queue {
  node *head, *tail; 
} queue;
void queue_init(queue *myroot);
void queue_put(queue *myroot, node *mynode);
node *queue_get(queue *myroot);


/* queue.c
** Copyright 2000 Daniel Robbins, Gentoo Technologies, Inc.
** Author: Daniel Robbins
** Date: 16 Jun 2000
**
** This set of queue functions was originally thread-aware.  I
** redesigned the code to make this set of queue routines
** thread-ignorant (just a generic, boring yet very fast set of queue
** routines).  Why the change?  Because it makes more sense to have
** the thread support as an optional add-on.  Consider a situation
** where you want to add 5 nodes to the queue.  With the
** thread-enabled version, each call to queue_put() would
** automatically lock and unlock the queue mutex 5 times -- that's a
** lot of unnecessary overhead.  However, by moving the thread stuff
** out of the queue routines, the caller can lock the mutex once at
** the beginning, then insert 5 items, and then unlock at the end.
** Moving the lock/unlock code out of the queue functions allows for
** optimizations that aren't possible otherwise.  It also makes this
** code useful for non-threaded applications.
**
** We can easily thread-enable this data structure by using the
** data_control type defined in control.c and control.h. */
#include <stdio.h>
#include "queue.h"
void queue_init(queue *myroot) {
  myroot->head=NULL;
  myroot->tail=NULL;
}
void queue_put(queue *myroot,node *mynode) {
  mynode->next=NULL;
  if (myroot->tail!=NULL)
    myroot->tail->next=mynode;
  myroot->tail=mynode;
  if (myroot->head==NULL)
    myroot->head=mynode;
}
node *queue_get(queue *myroot) {
  //get from root
  node *mynode;
  mynode=myroot->head;
  if (myroot->head!=NULL)
    myroot->head=myroot->head->next;
  return mynode;
}




-- 
gentoo-doc-cvs@gentoo.org mailing list