II. Corruption, Locking & Synchronization

1. As we talked about in the last lecture, threads can share state. 
1. e.g. if every instance of a class has a thread, then they share access to the class variables.
2. This can be a problem!
3. The classic example:  An ATM (automatic teller machine).
1. Suppose I and my partner are standing at two ATMs right next to each other.
2. I want to transfer money from our checking account to my savings account.
3. My partner wants to take money out of my checking account.
4. Suppose that these are the threads that get run:
   

   //My Thread
   transferAmount = ATM.getTypedNumber();
   float checkingTotal = checking.getBalance();
   float savingsTotal = savings.getBalance();
   // would really have to catch if this makes the checkingTotal < 0!
   checkingTotal -= transferAmount;  
   savingsTotal += transferAmount;
   checking.setBalance(checkingTotal);
   savings.setBalance(savingsTotal);
   
   // My Partner's Thread
   withdrawalAmount = ATM.getTypedNumber();
   float checkingTotal = checking.getBalance();
   // would really have to catch if this makes the checkingTotal < 0!
   checkingTotal -= withdrawalAmount;
   ATM.squirtMoneyOut(withdrawelAmount);
   checking.setBalance(checkingTotal);
    

5. What makes ATM examples interesting is the squirtMoneyOut command.
1. Once the customer has the money, nothing the program can do will get it back!!
2. From a computer science perspective, squirting money is a side effect, but it has irrevocable consequences in the real world.
   
6. Now suppose that both of our threads read the original checking balance from before either of us has changed it.
1. We get free money! 
2. The final checking balance will only reflect either the withdrawal or the transfer, not both!
3. We have more money in savings and my partner has cash too.
7. This may sound cool, but actually it's not.
1. If we'd been depositing money, we could have lost money in the same way.
2. No nation / economy can do very well if their banks don't work better than this!
8. The solution is called locking. 
1. If a thread is going to do multiple things to some memory / state / a variable (esp. read it then change it!) then it locks that variable.
2. A lock prevents other threads from accessing the value.
3. If they try to, they block - basically they wait until they can get access to it.
9. In Java, for some reason a lock is called a semaphore -- here's some notes on the topic.
1. the basic idea with a lock is that every object threads might share is associated with exactly one lock.
2. only one thread can hold the lock at a time.
3. It is important to hold the lock for as short of a time as possible, and then release it.  Otherwise, you make other threads wait and slow down the program.
4. E.g. if my partner had to wait for money while I was looking at our balance on screen.
   
10. Originally, all locking in Java was done with implicit (vs explicit) locks via synchronization.  This is still an available mechanism, so I'll show it to you here.
    
11. There are two ways to use synchrony:
1. synchronized methods, and
2. synchronized statements.
12. Only one thread can call synchronized code on an object at a time.  One way to do this is by declaring synchronized methods:
    

    public synchronized float debitAccount (Account a, float amount) {
        if (a.getBalance - amount < 0) {
    	throw new BalanceLTZeroException ("some clever message");
        }
        a.setBalance(a.getBalance() - amount);
        return (a.getBalance());
    }

13. Notice that I haven't only solved the problem by creating a synchronized method.  
14. I also had to create essentially a new way of accessing the account balance.  All other accessors should either be synchronized, made private or got rid of!
1. This is because we haven't really locked the attribute, we've locked a method.
2. If you want to lock just individual elements of data rather than code, you need to use a database (more on this next year!)
15. If your method is long you may not want to declare the whole thing synchronized.
1. Don't want to cut down on parallelism.
2. Want to let other threads have a go.
16. The synchronize statement is another way to create synchronized code.
    

    float checkingTotal;
    synchronize (checking) {
        checkingTotal = checking.balance();
        checkingTotal -= transferAmount;  
        checking.balance(checkingTotal);
    }
    System.Out.printline("You have "+ checkingTotal +" in your checking account");

1. Notice synchronize in this context takes an argument (an object)
1. Every object has an implicit lock, which is what locks when you call a synchronized method.
2. If you use that object in the synchronize statement, it will also lock any other access to that object with synchronized code using either way of synchronizing.
3. You can also create objects just to use their locks if you want to have finer-grained locking.
   
2. Notice: you can still get at the object if you use unsynchronized code!
   
3. So in other words, this only blocks access from synchonized methods of the object, or of other (or the same!) synchronized program blocks.
4. Java locks code, not data.
1. You have to synchronize a lot of things!
2. Most people wind up using databases to address this (see next year.)
   
17. Again, you don't want to do this very often or for very long bits of code, because that will reduce the benefit of having threads in the first place.

---

This is how far we got in class in 2006... but we got through it all in 2007 (from here took 10 minutes.) Finished OK most years if skipped Class Class.  2015 finished early even including Class Class, partly by doing a lot of the code from the laptop projector.

III. Liveness & Deadlock

1. Locking sounds great, right?  But what if my partner and I are running threads like this?
   

   //My Thread
   synchronize (checking) {
       synchronize(savings) {
   	// do stuff to our accounts...
       }
   }
   
   // My Partner's Thread
   synchronize (savings) {
       synchronize(checking) {
   	// do stuff to our accounts...
       }
   }
   

2. If we are very unlucky, my thread will get just enough time on its first slice to lock checking, while my partner's will have just enough time to lock savings.
1. From then on, whenever our threads get a slice, they will still be blocked!
2. This is called deadlock.
3. Important fact about luck and computers: computers do things fast enough and often enough that however unlikely something may be, if it's possible at all it will happen eventually.  Probably it will happen often!
3. There are a lot of ways to avoid deadlock, but none of them are perfect!
1. You can make an ordering of how locks should be acquired.  Then the above could never happen... if no mistake was ever made!
2. You can have some process (e.g. the scheduler) notice when a process hasn't done anything for a very long time & interrupt it. 
1. This lets the other process go.
2. But it means you have to plan for the possibility that you may not finish your thread (should always think about that anyway.)
3. You could make all the resources you need attributes of a larger object, then lock / synchronize that.
   
4. Although it's important to allow for interrupts, the main way to avoid deadlock is with careful engineering and good design patterns.
5. Note that even if you aren't entirely deadlocked, you can be blocked a lot of the time if everything is synchronized.
1. Not being blocked too much is called liveness.
2. If you don't have much liveness then there's not much point in using threads!
   

IV. Other Threading Notions

1. Thread groups & security:
1. Unless you say otherwise, thread is grouped with its parent (the thread that called it.)
2. Threads groups are used to determine security --- if you are running on the internet, you might not want just any thread to be able to manipulate you!
3. See article listed below in summary.
   
2. Livelock:
1. Sort of like deadlock, but the difference is that the threads keep waking up, but can't really do anything and go back to sleep.
2. Harder to detect by the scheduler than deadlock because it looks like they are doing something, they aren't just blocked.
3. Has to be dealt with through engineering.
4. Have a look on the discussions about Liveness on the Sun Oracle Java Tutorial listed below.
3. The producer / consumer pattern.
1. Helps you deal with two things happening at different rates.
2. Something may produce information / signals & another thing needs to process / `consume' that data, but at a different rate.
   
3. Implementing this pattern involves using wait / notify.
4. Sun Oracle recommends doing this using Guarded Blocks.
4. More sophisticated locking in Java  Don't mention in lecture, won't be on exam.
1. Allows you to work with an explicit lock object.
2. Is both more powerful & more complicated.
   
3. The problem with complexity in locks is deadlock, livelock.
4. The interface Lock documentation is interesting (& may help you understand implicit locks better.)
5. Probably this is archaic now that there are semaphores, sorry I ran out of time & haven't checked.
   

V. Summary

1. Threads are a huge topic we are barely touching.  If you are curious here's some more links:
1. Usenix article about threads, thread groups & thread management.
2. developers discussing how tight is too tight for a loop.
3. Most useful resource: the Sun Oracle Java Tutorial on Threads.
   
2. The most important things in this lecture have been:
1. How to deal with interrupts, avoiding overly tight loops.
2. The notion of locking and the mechanics of using synchronize
1. on methods,
2. on objects.
3. The notion of deadlock - how does it happen?  What does it mean?  What helps avoid it?

---

page author: Joanna Bryson
  3 March 2015