Thread Synchronization

• This is chapter 30
• A race condition occurs when
  • The output is dependent on the results of the sequence two or more operations
• Race conditions don't (normally) occur in sequential processing
  • The order of operations is deterministic, IE we know when things will happen.
  • Even with optimizing compilers and hardware
    • The rule is you can reorder the instructions but only if they produce the exact same results.
• But in the world of parallel race conditions are common
  • Generally when data is shared
  • Especially when writing data.
• Race conditions are very VERY difficult to find
  • They are non-deterministic
  • IE they depend on the scheduling order of the threads/processes
  • This means they are hard to recreate.
  • Especially if they are rare occurrences
• He gives an example in the book
  • I have rewritten this as race.C
  • In c/c++ volatile
    • Tells the compile to not keep this register resident.
    • Or do any other optimizations to improve speed.
    • This is intended for thread processing.
  • in c/c++ static places a variable in the static space.
    • if you want a thread local variable use
    • static thread_local variable definition;
  • Take a look.
• Look at the problem with glob++
  • This is not an atomic operation

  • lw  $t0, 0(glob)
    addi $t0, $t0, 1
    sw  $t0, 0(glob)
    	 

  • The os may swap the process out at any time.
  • It is even worse when threads are executing in parallel.
  • Take a look at Figure 30-1 p 633
• The solution to this problem is mutual exclusion or mutex
  • This solution requires a special hardware instruction
    • This instruction must be atomic or a single instruction so it can not be interrupted.
    • Some form of test and set:

      • if (M[adr] == 0) {
            M[adr] = 1
            return success
        } else {
            return fail
        }
        		   

• With mutex
  • You identify the critical sections in your code
    • These are sections where only one thread of execution should execute at a time.
    • Changing a variable
    • Performing I/O
  • You then use mutex to limit access to a variable.
• A mutex has two states
  • Locked, some process is in the critical section.
  • To lock a mutex you acquire the mutex.
  • Acquiring a mutex is normally a blocking operation
  • Unlocked no process is in the critical section.
  • To unlock a mutex you release the mutex.
• In general you need to

  lock the mutex associated with a critical variable
  update the variable
  unlock the mutex associated with that variable.
      

• A note of caution
  • You must be careful to release the mutex after you are finished
  • Failure to do so will result in deadlock.
• Deadlock occurs when two or more processes are waiting for a resource held by other processes
  • Deadlock becomes possible when Mutual exclusion is employed
  • Consider a table of philosophers.
    • There are n philosophers
    • Each philosopher has a plate of food.
    • Between each philosopher is 1 chopstick.
    • Philosophers either think or eat.
    • When a philosopher wants to eat
      • Pick up the right chop stick when it becomes available
      • Pick up the left chop stick when it becomes available
      • Eat
      • Put down the right chop stick
      • Put down the left chopstick
  • The problem is, if all philosophers want to eat at once time, they will starve.
  • Deadlock
    • Is best if avoided, IE make it so it can't occur.
    • But sometimes it must be detected and broken or find out that it is happening and make it stop.
  • For our philosophers
    • We could check to see if all philosophers are holding a chop stick.
    • If so, we tell the last one to put down their chopstick
  • Or we could number the chop sticks
    • And tell the philosophers that when they want to eat they must
      • Pick up the lowest numbered chop stick first.
      • Then the higher number.
• Deadlock in programs is a problem when there are
• The pthread package provides mutual exclusion
  • A mutex variable
    • a pthread_mutex_t is the pthread implementation of a mutex.
    • PTHREAD_MUTEX_INITIALIZER is a default state for such a mutex.
    • We will use statically allocated mutexes for now.
  • You can lock a mutex with int pthread_mutex_lock(pthread_mutex_t *mutex);
    • 0 on success, errno on error
    • This will block if the mutex is locked
    • On successful return, the mutex object is locked.
    • relocking a locked mutex is bad (Deadlock or undefined)
  • int pthread_mutex_unlock(pthread_mutex_t *mutex);
    • Same as above
    • If you attempt to unlock something that is not locked or that you don't own the behavior is undefined.
  • int pthread_mutex_trylock(pthread_mutex_t *mutex);
    • Returns immediately the mutex is locked.
      • If the mutex is locked by this thread it returns EDEADLK
      • If the mutex is locked by another thread it returns EBUSY
    • He suggests that this is a way to implement deadlock avoidance.
  • int pthread_mutex_timedlock(pthread_mutex_t *restrict mutex, const struct timespec *restrict abstime);
    • either locks the mutex
    • Or returns after a specified time
    • timespec defined in time.h

    • struct timespec {
          __time_t tv_sec;            /* Seconds.  */
          __syscall_slong_t tv_nsec;  /* Nanoseconds.  */
      }
      

• Look at raceFixed.C
• Adding mutex will definitely slow down a program
  • But it makes the program work.
• There are three different types of mutex variables specified in posix
  • PTHREAD_MUTEX_NORMAL
    • No deadlock detection
    • Locking a mutex second time is undefined
    • Unlocking incorrectly is undefined.
  • PTHREAD_MUTEX_ERRORCHECK
    • Errors are returned when lock/unlock errors occur
    • These are slower
    • He mentions useful in debugging.
  • PTHREAD_MUTEX_RECURSIVE
    • Error on bad unlock
    • Maintains a lock count on locking behavior
  • PTHREAD_MUTEX_DEFAULT is defined but not really
    • It is up to the system implementer
    • On linux it is PTHREAD_MUTEX_NORMAL
  • See man page for pthread_mutex_lock
• These are changed with
  • int pthread_mutexattr_settype(pthread_mutexattr_t *attr, int type);
    • The type is as above.
    • An mutexattr_t is created with
      • int pthread_mutexattr_init(pthread_mutexattr_t *attr);
    • And destroyed with
      • int pthread_mutexattr_destroy(pthread_mutexattr_t *attr);