Intro To Java Week 4 Wednesday, November 19, 14 Homework Review - - PowerPoint PPT Presentation

Intro To Java Week 4

Wednesday, November 19, 14

Homework Review

Week 1 Hadamard Week 2 Rational, Complex, Stack, CSV

Wednesday, November 19, 14

Recap

Generics Can’ t be used with primitives(but can use wrapper

• bjects)

Collections Use generics extensively Key interfaces: Collection, Set, List, Map Key implementations: HashSet, HashMap, ArrayList

Wednesday, November 19, 14

Why Concurrency?

People expect and demand it iTunes, OSes, web servers Multi-server, single queue Performance gains, exploit concurrent hardware Reliability - a thread can die, w/o killing entire prog Some tasks are inherently “concurrent” Robot walking in real time Networking Developers sometimes forced by use of a package to deal with concurrency - like a GUI

Wednesday, November 19, 14

In General, Concurrency Is Difficult!!

Like memory management, complex schemes are very difficult to get right and debug Systems can run fine for a year yet still be broken - time bombs We will survey some of the issues, but do not expect to master anything Java concurrency tools are excellent - there are lots

• f things can be built w/o expertise

Wednesday, November 19, 14

Concurrency In Hardware

Can get “appearance” of concurrency on single CPU by time slicing threads Multiple core CPUs now common. Can distribute threads across different cores

Wednesday, November 19, 14

Deprecated

In older code (pre 1.5), new Threads would be made by explicitly instantiating Thread objects, and perhaps calling “join” to wait for a Thread to terminate Thread, ThreadPool, Timer, TimerTask Executors provides thread pools and timer functionality wait(), notify(), notifyAll(), start(), stop(), resume() interrupts - just a flag, not like control-C Probably the only thing you want to use Thread for is Thread.sleep()

Wednesday, November 19, 14

Processes vs Threads

A “process” is provided by the OS. Heavyweight

• bject, with isolated address space

A “thread” is provided by the JVM. Lightweight

• bject, shares address space with all other threads

Generally IO is much slower than CPU, so having multiple threads reduces the amount of CPU idle time Threads can distribute to different “cores” on multi- core CPUs

Wednesday, November 19, 14

java.util.concurrency

Execution - manage thread lifecycle Synchronizers - coordinate groups of threads Locks - mutual exclusion synchronized statement Atomics - shared state w/o locks Fork/Join - divide and conquer

Wednesday, November 19, 14

Resource Pools

Normally “new” classes, use the objects for awhile, forget them, and the GC picks them up for us Some resources(represented by a class) are too expensive for this approach, so they are explicitly managed and recycled

Wednesday, November 19, 14

Thread Pools

Threads are expensive to make, start, and destroy. Don’ t want the extra latency Thread resources may not be freed for some time If you make a new thread for every task, can wind up with too many threads contending for system resources - very inefficient Better to size thread pool relative to hardware resources, and queue tasks if necessary

Wednesday, November 19, 14

java.util.concurrent.Executors

Big collection of static methods for making Executors

• f various types. Better than overloading constructor

Executor manages a resource pool of threads Will replace a thread that dies Provides lifecycle tools like shutdown() Passes tasks to idle threads, and reclaims the thread when it finishes for the next task

Wednesday, November 19, 14

java.lang.runnable

An interface - a class implements it by providing method public void run() {...} Executor will supply a thread to execute the run method No value or errors are returned example: RUN

Wednesday, November 19, 14

Callable and Future

Callable<T> is a generic interface. class implements it by providing method public T call() throws Exception {...} Executor supplies a thread to compute call(), returns a Future<T> Future tracks the async progress of call() cancel(), if it has not already started get(), get the value returned by call(), or the error it threw example: callfut

Wednesday, November 19, 14

Synchronizers

Force threads to wait for various conditions to become true Constructors can NOT be synchronized - they are called by “new” Lock objects more flexible, but harder to use

Wednesday, November 19, 14

Semaphore

Classic concurrency primitive Starts with initial count of “permits” acquire() grabs a permit, if available. otherwise blocks until it can get one release() returns a permit

Wednesday, November 19, 14

CountDownLatch

Given an initial count Calling countDown() decrements the count Any number of calls to await() block until the count = Not resetable example: CntDown

Wednesday, November 19, 14

CyclicBarrier

Given an initial count N await() calls will block until N threads have called it, then await() will return Optionally, a Runnable can be called when the Barrier is crossed Can be reused example: cb

Wednesday, November 19, 14

ExecutorCompletionService

Submit N Callable tasks As tasks complete, can pull futures off in completion

• rder from a queue

example: complete

Wednesday, November 19, 14

Exchanger<T>

Thread A calls an exchanger with a T1, and blocks Thread B calls the exchanger with a T2, and gets back T1, and Thread A gets back T2

Wednesday, November 19, 14

One Shot and Periodic Tasks

Special Executor handles time based “Runnable” tasks example: scheduled If you need complex scheduling, including “cron” style specs, look at the 3rd party Quartz scheduler

Wednesday, November 19, 14

Fork/Join

Dynamic divide and conquer. keep subdividing a task until it is small enough to complete example: fj

Wednesday, November 19, 14

example: contend

Try synchronized, synchronized(this), synchronized(lock), atomic

Wednesday, November 19, 14

example: contend

Race problem btw the two threads - cnt++ is NOT atomic Try synchronized, synchronized(this), synchronized(lock) - 10X slower! atomic - 3X slower

Wednesday, November 19, 14

Races

Outcome depends on who crosses the finish line first. Code below is broken / / Want expensive to be a singleton class Foo() { static Expensive expensive; Expensive getExpensive() { if (null == expensive) expensive = new Expensive(); return expensive; } }

Wednesday, November 19, 14

Eliminate the Race With a Lock

Outcome depends on who crosses the finish line first / / Want expensive to be a singleton class Foo() { static Expensive expensive; synchronized Expensive getExpensive() { if (null == expensive) expensive = new Expensive(); return expensive; } }

Wednesday, November 19, 14

Locks

synchronized method - sets up a “mutex” (mutual exclusion, critical section, one thread at a time region) Locks are somewhat expensive - OS is involved, threads must be suspended and resumed, which involves context swapping Sounds alot like databases - ACID Atomic, Consistent, Isolated (but not Durable) STM - Software Transactional Memory

Wednesday, November 19, 14

Three Types of Synchronized Statements

/ / ANY exit - normal, thrown error, releases the lock class Foo { / / Lock object is “Foo.class” (class literal). locks the method synchronized static void bar() { ... } / / Lock object is “this”, the instance itself. locks the method synchronized void zip() { ... } / / ANY object can be used as a lock Object lock = new Object(); void zap() { ... synchronized(lock) { / / this block is protected} ...}

Wednesday, November 19, 14

How Bad Can It Get? 1

example: DL

Wednesday, November 19, 14

Deadlocks

Some can avoided by always requesting resources in the same order Bob & Larry are doing house repairs. They both need a hammer and a screwdriver Also known romantically as a “deadly embrace”

Wednesday, November 19, 14

How Bad Can It Get? 2

Prog might print zero, or maybe never print at all! class Yikes implements Runnable{ static boolean ready; static int num; public void run() { while(!ready) sleep(briefly); System.out.println(num) } public static void main(String args[]){ executor.execute(new Yikes()); num = 42; ready = true; }

Wednesday, November 19, 14

Instruction Reordering

All kinds of sneaky things are going on behind your back for performance might change num = 42; ready = true ready=true; num =42

• k to do because executing thread can’

t tell the difference - but OTHER threads can!!

Wednesday, November 19, 14

How Bad Can It Get? 3

Thread A sets up an instance of Yikes ThreadB calls Yikes.mustBeTrue() due to cache changes, method might return FALSE!! class Yikes { private int n; public Yikes(int n) { this.n = n; } public boolean mustBeTrue() { n == n } }

Wednesday, November 19, 14

Independent Caches

First and second read of n could fetch different values, depending on what happens with the caches Java Memory Model allows this, because if values were always “up to date” it would render the caches worthless Get huge speedups with caches - main memory is very slow Sometimes variables are in a CPU register - an even faster “cache”

Wednesday, November 19, 14

synchronized - Act 2

Weirdly, not well known or advertised synchronized, and other forms of locks, have the side effect of making changes in one thread VISIBLE to

• ther threads

update and retrieval must be done with the SAME lock making data “visible” to other threads is known as “publishing” class Foo { private int num; synchronized int getNum() {return num;} synchronized void setNum(int n) { num = n; } }

Wednesday, November 19, 14

Safe Publication Techniques

static init class Foo { static Yikes y = new Yikes(5); ...} which is NOT the same as: class Foo { static Yikes y; void make() { y = new Yikes(5); } Placing and retrieving a value from Concurrent Collection objects Exchanger

Wednesday, November 19, 14

Immutable Objects are ALWAYS publication-safe

This is fine class Im {final int x; final int y;} Is this safe? class Im2 {final int x; final ArrayList<Long> al}

Wednesday, November 19, 14

Atomics

Nice because they don’ t lock - faster than locks Implemented by CompareAndSwap instruction Some limitations tho - code below is broken class CacheLongFunc { AtomicInteger lastIn = new AtomicInteger(); AtomicInteger lastOut = new AtomicInteger(); int longComputation(int in) if (lastIn == in) return lastOut; lastIn = in; lastOut = longFunc(in); return lastOut; } }

Wednesday, November 19, 14

Atomics

Code correct, fixed race - but too slow - longFunc is inside the lock want to minimize amount of time a lock is held - hurts concurrency safety vs “liveness” class CacheLongFunc { AtomicInteger lastIn = new AtomicInteger(); AtomicInteger lastOut = new AtomicInteger(); synchronized int longComputation(int in) if (lastIn == in) return lastOut; lastIn = in; lastOut = longFunc(in); return lastOut; }}

Wednesday, November 19, 14

Atomics

Keep longFunc out of locked section, at cost of getting two locks class CacheLongFunc { AtomicInteger lastIn = new AtomicInteger(); AtomicInteger lastOut = new AtomicInteger(); int longComputation(int in) synchronized(this){ if (lastIn == in) return lastOut; }

• ut = longFunc(in);

synchronized(this){ lastIn = in; lastOut = out; } return lastOut;}}

Wednesday, November 19, 14

Volatile Variables

Dicey Tells compiler and runtime variable cannot be cached Can cause lots of cache blowouts If used in a loop will be very slow

Wednesday, November 19, 14

Synchronized Collections

“Wrap” the non-concurrent collections in a “synchronized wrapper” Use java.util.Collections.sychronizedList(), etc Can be useful, but is a retrofit. Doesn’ t cover everything

Wednesday, November 19, 14

Synchronized ArrayList

SyncArrayList can’ t get messed up, but caller can still lose public static Object getLast(SyncArrayList list) { int lastIndex = list.size() - 1; return list.get(lastIndex); } public static void deleteLast(SyncArrayList list) { int lastIndex = list.size() - 1; list.remove(lastIndex); }

Wednesday, November 19, 14

Concurrent Collections Classes

VERY carefully crafted classes Also magically handle correct publishing of objects concurrenthashmap.put(newobj, newobj); pubobj = concurrenthashmap.get(newobj);

Wednesday, November 19, 14

ConcurrentHashMap

Very fast has multiple locks, so threads can hit different parts of the map without contending putIfAbsent(key, val) - atomic operation

Wednesday, November 19, 14

CopyOnWriteArrayList

Works well when doing lots of iteration, but little

• modification. For example, maintaining lists of event

listeners Any modification causes a new copy of the array to be made Existing iterators will not throw a ConcurrentModificationException, like non-current ArrayList, but iterator will not see the changes Next iterator requested will see changes

Wednesday, November 19, 14

BlockingQueue Interface

Implementations come in many flavors Fixed and variable capacity versions With or without blocking Throw errors or return status Swiss army knife

Wednesday, November 19, 14

Unmodifiable Collections

May have a collection that is “protected by an encapsulating object” - don’ t want it modified by anything outside But, can give the world an “unmodifiable collection” - read-only access to the primary collection

Wednesday, November 19, 14

GUI/Window Systems

Modern GUI’ s are all single threaded. Users put requests on a BlockingQueue MIT Lisp Machine Window System was concurrent. Great functionality, but locked up frequently Choose your concurrency battles carefully:

I believe you can program successfully with multithreaded GUI toolkits if the toolkit is very carefully designed; if the toolkit exposes its locking methodology in gory detail; if you are very smart, very careful, and have a global understanding of the whole structure of the toolkit. If you get one of these things slightly wrong, things will mostly work, but you will get occasional hangs (due to deadlocks) or glitches (due to races). This multithreaded approach works best for people who have been intimately involved in the design of the toolkit. Unfortunately, I don't think this set of characteristics scales to widespread commercial use. What you tend to end up with is normal smart programmers building apps that don't quite work reliably for reasons that are not at all obvious. So the authors get very disgruntled and frustrated and use bad words on the poor innocent toolkit.

Wednesday, November 19, 14