CS360 Lecture notes -- Thread #1

  • Jim Plank
  • Directory: /home/plank/cs360/notes/Thread1
  • Lecture notes: http://www.cs.utk.edu/~plank/plank/classes/cs360/360/notes/Thread1/lecture.html
    Last revised: Mon Apr 11 11:20:05 EDT 2016
    Threads programming is a paradigm of programming that is very powerful and natural. In a nutshell, threads let you have multiple processing units, called ``threads'' that cooperate via shared memory.

    Why threads?

    There are many reasons to program with threads. In the context of this class, there are two important ones:
    1. They allow you to deal with asynchronous events synchronously and efficiently.
    2. They allow you to get parallel performance on a shared-memory multiprocessor.
    You'll find threads to be a big help in writing an operating system. Therefore, by learning threads here, you get a leg up on your OS class (that is, if they make you write an operating system....).

    What are threads?

    What are threads? Threads are often called "lightweight processes". Whereas a typical process in Unix consists of CPU state (i.e. registers), memory (code, globals, heap and stack), and OS info (such as open files, a process ID, etc), in a thread system there is a larger entity, called a "task", a "pod", or sometimes a "heavyweight process."

    The task consists of a memory (code, globals, heap), OS info, and threads. Each thread is a unit of execution, which consists of a stack and CPU state (i.e. registers). Multiple threads resemble multiple processes, except that multiple threads within a task use the same code, globals and heap. Thus, while two processes in Unix can only communicate through the operating system (e.g. through files, pipes, or sockets), two threads in a task can communicate through memory.

    When you program with threads, you assume that they execute simultaneously. In other words, it should appear to you as if each thread is executing on its own CPU, and that all the threads share the same memory.

    There are various primitives that a thread system must provide. Let's start with two basic ones. In this initial discussion, I am talking about a generic thread system. We'll talk about specific ones (such as POSIX) later.


    Posix threads

    On most Unix machines, there is a thread system that you can use. It is called ``Posix threads.'' To make use of Posix threads in your program, you need to have the following include directive:
    #include <pthread.h>
    
    And you have to link libpthread.a to your object files. (i.e. if your program is in main.c, you need to do the following to make your thread executable):
    UNIX> gcc -c main.c
    UNIX> gcc -o main main.o -lpthread
    
    You can use pthreads with g++ too. There's a lot of junk in the pthread library. You can read about it in the various man pages. Start with ``man pthreads''. The two basic primitives defined above are the following in Posix threads:
         int pthread_create(pthread_t *new_thread_ID,
                            const pthread_attr_t *attr,
                            void * (*start_func)(void *), 
                            void *arg);
    
         int pthread_join(pthread_t target_thread, 
                          void **status);
    
    This isn't too bad, and not too far off from my generic description above. Instead of returning a pointer to a thread control block, pthread_create() has you pass the address of one, and it fills it in. Don't worry about the attr argument yet -- just use NULL. Then func is the function, and arg is the argument to the function, which is a (void *). When pthread_create returns, the TCB is in *new_thread_ID, and the new thread is running func(arg).

    pthread_join() has you specify a thread, and give a pointer to a (void *). When the specified thread exits, the pthread_join() call will return, and *status will be the return or exit value of a thread.

    In all the Posix threads, calls, an integer is returned. If zero, everything went ok. Otherwise, an error has occurred. As with system calls, it is always good to check the return values of these calls to see if there has been an error. In my code here in the lecture notes, I'll omit error checking, but it is in the files, and you should do it.

    How does a thread exit? By calling return or pthread_exit().

    Ok, so check out the following program (in hw.c):

    #include <pthread.h>
    #include <stdio.h>
    #include <stdlib.h>
    
    void *printme()
    {
      printf("Hello world\n");
      return NULL;
    }
    
    main()
    {
      pthread_t tcb;
      void *status;
    
      if (pthread_create(&tcb, NULL, printme, NULL) != 0) {
        perror("pthread_create");
        exit(1);
      }
      if (pthread_join(tcb, &status) != 0) { perror("pthread_join"); exit(1); }
    
    }
    

    Try copying hw.c to your home area, compiling it, and running it. It should print out ``Hello world''.


    Forking multiple threads

    Now, look at print4.c.

    #include <pthread.h>
    #include <stdio.h>
    
    void *printme(void *ip)
    {
      int *i;
    
      i = (int *) ip;
      printf("Hi.  I'm thread %d\n", *i);
      return NULL;
    }
    
    main()
    {
      int i, vals[4];
      pthread_t tids[4];
      void *retval;
    
      for (i = 0; i < 4; i++) {
        vals[i] = i;
        pthread_create(tids+i, NULL, printme, vals+i);
      }
    
      for (i = 0; i < 4; i++) {
        printf("Trying to join with tid %d\n", i);
        pthread_join(tids[i], &retval);
        printf("Joined with tid %d\n", i);
      }
    }
    

    This forks off 4 threads that print out ``Hi. I'm thread n'', where n goes from zero to 3. The main thread calls pthread_join() so that it waits for all four threads to exit before it exits. This should give you a good idea of how multiple threads can co-exist in the same process.

    Here's the output of three different calls to print4.c:

    UNIX> print4
    Trying to join with tid 0
    Hi.  I'm thread 0
    Hi.  I'm thread 1
    Hi.  I'm thread 2
    Hi.  I'm thread 3
    Joined with tid 0
    Trying to join with tid 1
    Joined with tid 1
    Trying to join with tid 2
    Joined with tid 2
    Trying to join with tid 3
    Joined with tid 3
    UNIX> 
    
    Here's what happened: The main() program got control after forking off the four threads. It called pthread_join for thread zero and blocked. Then thread zero got control, printed its line, and exited. Next came threads one, two and three. When they finished, the main() thread got control again and since thread zero was done, its pthread_join() call returned. Then it made the pthread_join() calls for threads one, two and three, all of which returned since these threads were done. When main() returned, all the threads are done, and the program exited.

    Now, that's not the only possible output of the program. In particular, here are three more runs of the program, which all have different outputs:

    UNIX> print4
    Hi.  I'm thread 0
    Hi.  I'm thread 1
    Hi.  I'm thread 2
    Trying to join with tid 0
    Joined with tid 0
    Trying to join with tid 1
    Joined with tid 1
    Trying to join with tid 2
    Joined with tid 2
    Trying to join with tid 3
    Hi.  I'm thread 3
    Joined with tid 3
    UNIX> print4
    Hi.  I'm thread 0
    Hi.  I'm thread 2
    Trying to join with tid 0
    Joined with tid 0
    Trying to join with tid 1
    Hi.  I'm thread 1
    Joined with tid 1
    Trying to join with tid 2
    Joined with tid 2
    Trying to join with tid 3
    Hi.  I'm thread 3
    Joined with tid 3
    UNIX> print4
    Hi.  I'm thread 2
    Hi.  I'm thread 3
    Hi.  I'm thread 0
    Hi.  I'm thread 1
    Trying to join with tid 0
    Joined with tid 0
    Trying to join with tid 1
    Joined with tid 1
    Trying to join with tid 2
    Joined with tid 2
    Trying to join with tid 3
    Joined with tid 3
    UNIX> 
    
    You'll note that these are quite different. Each of them is the result of the threads getting scheduled in different orders. Let's think about this more. In particular, think about what's going on after the main thread calls pthread_create() for the first time. At that point, there are two threads -- the main thread and thread 0. Either of them can run, and it's up to the operating system to select one. If the operating system is managing two processors, it may choose to run each thread simultaneously on a different processor.

    If thread 0 gets control first, you'll see the output "Hi. I'm thread 0" first. If the main thread gets control first, then it will call pthread_create() for thread 1, and you'll have three threads that can all run. For each output above, you can derive an ordering of the threads that generates the output. For example in that last output, the main thread creates thread 2 before the first line of output is printed, and that line is printed by thread 2.

    This is simultaneously what makes threaded programs great and difficult. They are great because they allow multiple threads to run at the same time (either on different processors, or on one processor, scheduled by the operating system). They are difficult for the same reason. One of the challenged of this type of programming is allowing for the threads to do as much as they can simultaneously without getting yourself in trouble.


    exit() vs pthread_exit()

    In pthreads there are two things you should know about thread/program termination. The first is that pthread_exit() makes a thread exit, but keeps the task alive, while exit() terminates the task. If all threads (and the main() program should be considered a thread) have terminated, then the task terminates. So, look at p4a.c.

    Here, all threads, including the main() program exit with pthread_exit(). You'll see that the output is the same as print4.

    Now, look at p4b.c. Here, we put a pthread_exit() call in main() before making the join calls. The output is:

    Hi.  I'm thread 0
    Hi.  I'm thread 1
    Hi.  I'm thread 2
    Hi.  I'm thread 3
    
    You'll note that none of the "Joining" lines were printed out because the main thread had exited. However, the other threads ran just fine, and the program terminated when all the threads had exited.

    The second thing you need to know is that when a forked thread returns from its initial calling procedure (e.g. printme in print4.c), then that is the same as calling pthread_exit(). However, if the main() thread returns, then that is the same as calling exit(), and the task dies. That's why there is no output in p4c.c.

    UNIX> p4c
    UNIX> 
    
    Threads 0 through 3 have been forked when the main thread exits, but they haven't run yet. When the main thread returns, the task is terminated, and thus the threads do not run.

    Finally, look at p4d.c. Here, the threads call exit() instead of pthread_exit(). You'll note that the output is:

    Trying to join with tid 0
    Hi.  I'm thread 0
    
    This is because the task is terminated by thread 0's exit() call.

    Preemption versus non-preemption

    Now, take a look at iloop.c. Here, four threads are forked off, and then the main() thread goes into an infinite loop. When you execute it, what do you think you'll see? I can think of two answers. One is that you'll see nothing -- the main() thread spins forever, and the other threads don't run. The second answer is that the main() thread will run, but the other threads will also get the CPU at some point and run to completion.

    The underlying issue here is called preemption. If your thread system is preemptive, then although the main thread gets most of the CPU, the thread system interrupts it at certain points (i.e. it preempts the main() thread), and runs the other threads.

    POSIX thread systems under Solaris used to be non-preemptive. Under LINUX, they are preemptive. So, in our labs (which are LINUX boxes), iloop runs as follows:

    UNIX> iloop
    Hi.  I'm thread 0
    Hi.  I'm thread 1
    Hi.  I'm thread 2
    Hi.  I'm thread 3
    

    There are some machines that have multiple CPU's attached to a single memory. These systems are by nature preemptive, since different threads will actually execute on different CPU's. However, whether or not a thread system is preemptive is an attribute that you must discern when you are programming for a thread system.

    A non-preemptive thread system on a system with a single CPU (called a "uniprocessor") may seem useless, but in actuality it is extremely useful.


    Pthread_detach()

    Threads consume resources. In particular, each thread executes on its own stack, which requires memory. When a thread exits, the thread system has to decide whether to release its resources or not. It makes that decision in one of two ways:

    1. If another thread calls pthread_join() on the thread, then upon completion of the pthread_join() call, the thread's resources are released.

    2. If any thread (typically the thread itself) calls pthread_detach() on the thread, then no pthread_join() call is required. The thread's resources will be released instantly when the thread exits. More often than not, it is what you want.

    To call pthread_detach() on yourself, you call

    pthread_detach(pthread_self());
    


    Threaded Telnet, and Minitalk Done Right

    Threads provide the perfect framework for writing programs that deal with asynchrony. In particular, in our lecture notes on sockets, we had some problems writing programs that needed to do the following operations simultaneously: We solved that problem by forking off processes. With threads, you can do these simultaneous operations in one process. That is often essential because you want your various operaions to share information.

    In this section, we'll first write a threaded telnet client. This is a client that will request a connection to a socket, and then do what we specify above -- anything typed into standard input will go to the socket, and anything that comes from the socket will go to standard output.

    The program is in th_telnet.c, and you should study it. The comments specify exactly what it is doing:

    #include <pthread.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include "sockettome.h"
    
    /* As input, this procedure takes an array of two FILE *'s, typecast to
       a void *.  Let's call this array "connection."  This procedure will read
       lines of text from from connection[0] and write them to connection[1].
       This is convenient, because it works regardless of whether the FILE *'s 
       are socket connections or stdin/stdout. */
    
    void *process_connection(void *c)
    {
      FILE **connection;
      char buf[1000];
    
      connection = (FILE **) c;
      while (fgets(buf, 1000, connection[0]) != NULL) {
        printf("Read: %s", buf);
        fflush(stdout);
        fputs(buf, connection[1]);
        fflush(connection[1]);
      }
      exit(0);
    }
    
    main(int argc, char **argv)
    {
      int fd;
      FILE *fin, *fout;
      FILE *stdin_to_socket[2];
      FILE *socket_to_stdout[2];
      pthread_t tid;
    
      if (argc != 3 || atoi(argv[2]) <= 0) {
        fprintf(stderr, "usage: th_telnet host port\n");
        exit(1);
      }
    
      /* Open a socket connection to a server, and convert the file 
         descriptor to two FILE *'s, one for reading and one for 
         writing. */
    
      fd = request_connection(argv[1], atoi(argv[2]));
      fin = fdopen(fd, "r");
      fout = fdopen(fd, "w");
      
      /* Create arrays of FILE *'s for process_connection. */
    
      stdin_to_socket[0] = stdin;
      stdin_to_socket[1] = fout;
    
      socket_to_stdout[0] = fin;
      socket_to_stdout[1] = stdout;
    
      /* Fork off a thread to read from the socket and print to standard output.
         The main thread will read from standard input and print to the socket. */
    
      pthread_create(&tid, NULL, process_connection, socket_to_stdout);
      process_connection(stdin_to_socket);
    
      exit(0);
    }
    

    Let's try it, using alternate from the Socket lecture notes as the server:

    UNIX> th_telnet localhost 5555
    Hey
    Read: Hey
    
    
    Read: Hey is for horses.
    Hey is for horses.
    I hate it when people say that.  
    Read: I hate it when people say that.  
    
    So stop saying that.
    Read: So stop saying that.
    
    Read: It is only proper.
    It is only proper.
    < CNTL-D >
    UNIX> 
    
    UNIX> alternate localhost 5555 s
    Connection established.  Client should start talking
    
    Hey
    Hey is for horses.
    
    
    
    
    I hate it when people say that.  
    
    
    It is only proper.
    So stop saying that.
    
    
    UNIX> 
    

    You'll note, when the left person wrote "So stop saying that," it was read and sent along the socket instantly. However, because alternate alternates strictly, it was not read from the socket until after the second person wrote "It is only proper."

    The program real_minitalk.c has both the client and server code for a two-person talk program. It is very much like th_telnet, except it has code for setting up the server, and it doesn't print the "Read" like like th_telnet. What you should notice is that it's ok for one of the two programs to type lots of input, and it works fine. That's because each program has two threads -- one to handle standard input, and one to handle the thread.

    UNIX> real_minitalk localhost 5555 c
    Hi
    
    I said Hi
    
    Why aren't you talking to me?
    
    Is it because I am overbearing?
    
    
    No.  Bye
    UNIX> 
    
    UNIX> real_minitalk localhost 5555 s
    
    Hi
    
    I said Hi
    
    Why aren't you talking to me?
    
    Is it because I am overbearing?
    No.  Bye
    
    UNIX>