![Thread Subclass
public class HelloThread extends Thread {
public void run() {
System.out.println("Hello from a thread!");
}
public static void main(String args[]) {
(new HelloThread()).start();
}
}](https://image.slidesharecdn.com/concurrencywithjava-160504180607/85/Concurrency-with-java-12-320.jpg)
![Implement Runnable Interface
public class HelloRunnable implements Runnable
{
public void run() {
System.out.println("Hello from a thread!"); }
public static void main(String args[]) {
(new HelloRunnable()).start();
}
}](https://image.slidesharecdn.com/concurrencywithjava-160504180607/85/Concurrency-with-java-13-320.jpg)
Concurrency with java
- 1. Programming Paradigms • Single Process • Multi Process • Multi Core/Multi Thread
- 3. Process • Process A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time.
- 4. Java Process Objects • ADTs, aggregate components, JavaBeans, monitors, business objects, remote RMI objects, subsystems, ... • May be grouped according to structure, role, ... • Usable across multiple activities — focus on SAFETY Activities • Messages, call chains, threads, sessions, scenarios, scripts, workflows, use cases, transactions, data flows, mobile computations
- 5. Thread • Threads are so called lightweight processes which have their own call stack but an access shared data. Every thread has its own memory cache. If a thread reads shared data it stores this data in its own memory cache. A thread can re-read the shared data
- 6. What is The Gain • Amdahl's Law • It states that a small portion of the program which cannot be parallelized will limit the overall speed-up available from parallelization. • A program solving a large mathematical or engineering problem will typically consist of several parallelizable parts and several non-parallelizable (sequential) parts. If p is the fraction of running time a sequential program spends on non-parallelizable parts, then • S = 1/p
- 7. How much is the speed up • If the sequential portion of a program accounts for 10% of the runtime, we can get no more than a 10× speed-up, regardless of how many processors are added. This puts an upper limit on the usefulness of adding more parallel execution units. "When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned
- 8. How does Java help to Parallel Programming • Has Threads since its inception • Threads have their own stack. But uses heap of the JVM • Has many constructs to control the concurrency • Programmer knowledge is very critical
- 10. Thread Class Constructors • Thread(Runnable r) constructs so run() calls r.run() • — Other versions allow names, ThreadGroup placement Principal methods • start() activates run() then returns to caller • isAlive() returns true if started but not stopped • join() waits for termination (optional timeout) • interrupt() breaks out of wait, sleep, or join • isInterrupted() returns interruption state • getPriority() returns current scheduling priority • setPriority(int priorityFromONEtoTEN) sets it
- 11. How to Implement a Thread • Subclass Thread. The Thread class itself implements Runnable, though its run method does nothing. An application can subclass Thread, providing its own implementation of run
- 12. Thread Subclass public class HelloThread extends Thread { public void run() { System.out.println("Hello from a thread!"); } public static void main(String args[]) { (new HelloThread()).start(); } }
- 13. Implement Runnable Interface public class HelloRunnable implements Runnable { public void run() { System.out.println("Hello from a thread!"); } public static void main(String args[]) { (new HelloRunnable()).start(); } }
- 14. Pausing while executing • Thread.sleep causes the current thread to suspend execution for a specified period. • This is an efficient means of making processor time available to the other threads of an application or other applications that might be running on a computer system. The sleep method can also be used for pacing
- 15. Thread Management • To directly control thread creation and management, simply instantiate Thread each time the application needs to initiate an asynchronous task. • To abstract thread management from the rest of your application, pass the application's tasks to an executor.
- 16. Sleep Example • main declares that it throws InterruptedException. This is an exception that sleep throws when another thread interrupts the current thread while sleep is active. Since this application has not defined another thread to cause the interrupt, it doesn't bother to catch InterruptedException.
- 17. Communicating with Thread • Interrupts • An interrupt is an indication to a thread that it should stop what it is doing and do something else. It's up to the programmer to decide exactly how a thread responds to an interrupt, but it is very common for the thread to terminate. This is the usage emphasized in this lesson.
- 18. Interrupt requirement • A thread sends an interrupt by invoking interrupt on the Thread object for the thread to be interrupted. For the interrupt mechanism to work correctly, the interrupted thread must support its own interruption.
- 19. Interrupt Status • The interrupt mechanism is implemented using an internal flag known as the interrupt status. Invoking Thread.interrupt sets this flag. When a thread checks for an interrupt by invoking the static method Thread.interrupted, interrupt status is cleared. The non-static isInterrupted method, which is used by one thread to query the interrupt status of another, does not change the interrupt status flag.
- 20. Interrupted Exception and Status • By convention, any method that exits by throwing an InterruptedException clears interrupt status when it does so. However, it's always possible that interrupt status will immediately be set again, by another thread invoking interrupt.
- 21. Thread Collaboration • The join method allows one thread to wait for the completion of another. If t is a Thread object whose thread is currently executing, • t.join(); • causes the current thread to pause execution until t's thread terminates. Overloads of join allow the programmer to specify a waiting period. However, as with sleep, join is dependent on the OS for timing, so you should not assume that join will wait exactly as long as you specify. • Like sleep, join responds to an interrupt by exiting with an InterruptedException.
- 23. Synchronization • Threads communicate primarily by sharing access to fields and the objects reference fields refer to. This form of communication is extremely efficient, but makes two kinds of errors possible: thread interference and memory consistency errors. The tool needed to prevent these errors is synchronization.
- 24. Synchronization Mechanisms • Thread Interference describes how errors are introduced when multiple threads access shared data. • Memory Consistency Errors describes errors that result from inconsistent views of shared memory. • Synchronized Methods describes a simple idiom that can effectively prevent thread interference and memory consistency errors. • Implicit Locks and Synchronization describes a more general synchronization idiom, and describes how synchronization is based on implicit locks. • Atomic Access talks about the general idea of operations that can't be interfered with by other threads.
- 25. Synchronization Libraries Semaphores Maintain count of the number of threads allowed to pass Latches Boolean conditions that are set once, ever Barriers Counters that cause all threads to wait until all have finished Reentrant Locks Java-style locks allowing multiple acquisition by same thread, but that may be acquired and released as needed Mutexes Non-reentrant locks Read/Write Locks Pairs of conditions in which the readLock may be shared, but the writeLock is exclusive
- 26. Semaphores Conceptually serve as permit holders • Construct with an initial number of permits (usually 0) • require waits for a permit to be available, then takes one • release adds a permit But in normal implementations, no actual permits change hands. • The semaphore just maintains the current count. • Enables very efficient implementation Applications • Isolating wait sets in buffers, resource controllers • Designs that would otherwise encounter missed signals — Where one thread signals before the other has even started waiting — Semaphores ‘remember’ how many times they were signalled
- 27. Counter Using Semaphores class BoundedCounterUsingSemaphores { long count_ = MIN; Sync decPermits_= new Semaphore(0); Sync incPermits_= new Semaphore(MAX-MIN); synchronized long value() { return count_; } void inc() throws InterruptedException { incPermits_.acquire(); synchronized(this) { ++count_; } decPermits_.release(); } void dec() throws InterruptedException { decPermits_.acquire(); synchronized(this) { --count_; } incPermits_.release(); } }
- 28. Using Latches • Conditions starting out false, but once set true, remain true forever • Initialization flags • End-of-stream conditions • Thread termination • Event occurrence
- 29. Using Barrier Conditions Count-based latches • Initialize with a fixed count • Each release monotonically decrements count • All acquires pass when count reaches zero
- 30. Liveness • A concurrent application's ability to execute in a timely manner is known as its liveness. This section describes the most common kind of liveness problem, deadlock, and goes on to briefly describe two other liveness problems, starvation and livelock.
- 31. Deadlock • Deadlock describes a situation where two or more threads are blocked forever, waiting for each other. Here's an example. • Alphonse and Gaston are friends, and great believers in courtesy. A strict rule of courtesy is that when you bow to a friend, you must remain bowed until your friend has a chance to return the bow. Unfortunately, this rule does not account for the possibility that two friends might bow to each other at the same time.
- 32. Starvation and Livelock • Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress. This happens when shared resources are made unavailable for long periods by "greedy" threads. • A thread often acts in response to the action of another thread. If the other thread's action is also a response to the action of another thread, then livelock may result.
- 33. Guarded Blocks • Threads often have to coordinate their actions. The most common coordination idiom is the guarded block. Such a block begins by polling a condition that must be true before the block can proceed. There are a number of steps to follow in order to do this correctly.
- 34. Guarded Block (cont..) • Constant polling for Condition • Use wait/notify method • Immutable Objects • Producer Consumer Example • A Synchronized Class Example
- 35. Immutable Object 1. Don't provide "setter" methods — methods that modify fields or objects referred to by fields. 2. Make all fields final and private. 3. Don't allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods. 4. If the instance fields include references to mutable objects, don't allow those objects to be changed: – Don't provide methods that modify the mutable objects. – Don't share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid returning the originals in your methods.
- 36. High Level Concurrency Objects • Lock objects support locking idioms that simplify many concurrent applications. • Executors define a high-level API for launching and managing threads. Executor implementations provided by java.util.concurrent provide thread pool management suitable for large-scale applications. • Concurrent collections make it easier to manage large collections of data, and can greatly reduce the need for synchronization. • Atomic variables have features that minimize synchronization and help avoid memory consistency errors. • ThreadLocalRandom (in JDK 7) provides efficient generation of pseudorandom numbers from multiple threads.
- 37. Lock Objects • Only one thread can own a implicit Lock object at a time. Lock objects also support a wait/notify mechanism, through their associated Condition objects. • The biggest advantage of Lock objects over implicit locks is their ability to back out of an attempt to acquire a lock. The tryLock method backs out if the lock is not available immediately or before a timeout expires (if specified). The lockInterruptibly method backs out if another thread sends an interrupt before the lock is acquired.
- 39. Executors • In large-scale applications, it makes sense to separate thread management and creation from the rest of the application. Objects that encapsulate these functions are known as executors. • Executor Interfaces define the three executor object types. • Thread Pools are the most common kind of executor implementation. • Fork/Join is a framework (new in JDK 7) for taking advantage of multiple processors.
- 40. Executor Interfaces • The java.util.concurrent package defines three executor interfaces: • Executor, a simple interface that supports launching new tasks. • ExecutorService, a subinterface of Executor, which adds features that help manage the lifecycle, both of the individual tasks and of the executor itself. • ScheduledExecutorService, a subinterface of ExecutorService, supports future and/or periodic execution of tasks.
- 41. The Executor Interface • The Executor interface provides a single method, execute, designed to be a drop-in replacement for a common thread-creation idiom. If r is a Runnable object, and e is an Executor object you can replace • (new Thread(r)).start(); • with • e.execute(r);
- 42. The ExecutorService Interface • The ExecutorService interface supplements execute with a similar, but more versatile submit method. Like execute, submit accepts Runnable objects, but also accepts Callable objects, which allow the task to return a value. The submit method returns a Future object, which is used to retrieve the Callable return value and to manage the status of both Callable and Runnable tasks. • ExecutorService also provides methods for submitting large collections of Callable objects. Finally, ExecutorService provides a number of methods for managing the shutdown of the executor. To support immediate shutdown, tasks should handle interrupts correctly.
- 43. The ScheduledExecutorService Interface • The ScheduledExecutorService interface supplements the methods of its parent ExecutorService with schedule, which executes a Runnable or Callable task after a specified delay. In addition, the interface defines scheduleAtFixedRate and scheduleWithFixedDelay, which executes specified tasks repeatedly, at defined intervals.
- 44. Thread Pools • Using worker threads minimizes the overhead due to thread creation. Thread objects use a significant amount of memory, and in a large- scale application, allocating and deallocating many thread objects creates a significant memory management overhead. • Tasks are submitted to the pool via an internal queue, which holds extra tasks whenever there are more active tasks than threads.
- 45. Thread Pools • newFixedThreadPool • newCachedThreadPool • newSingleThreadExecutor • For customized needs one can construct • java.util.concurrent.ThreadPoolExecutor or java.util.concurrent.ScheduledThreadPoolExec utor
- 46. Fork/Join • The fork/join framework is an implementation of the ExecutorService interface that helps you take advantage of multiple processors. It is designed for work that can be broken into smaller pieces recursively. The goal is to use all the available processing power to enhance the performance of your application.
- 47. Basic Use • if (my portion of the work is small enough) – do the work directly • else – split my work into two pieces – invoke the two pieces and wait for the results • After your ForkJoinTask is ready, create one that represents all the work to be done and pass it to the invoke() method of a ForkJoinPool instance.
- 48. Concurrent Collections • The java.util.concurrent package includes a number of additions to the Java Collections Framework • BlockingQueue • ConcurrentMap • ConcurrentSkipList • All of these collections help avoid Memory Consistency Errors by defining a happens-before relationship between an operation that adds an object to the collection with subsequent operations that access or remove that object.
- 49. Atomic Variables • The java.util.concurrent.atomic package defines classes that support atomic operations on single variables. All classes have get and set methods that work like reads and writes on volatile variables.
- 50. Concurrent Random Numbers • In JDK 7, java.util.concurrent includes a convenience class, ThreadLocalRandom, for applications that expect to use random numbers from multiple threads or ForkJoinTasks. • int r = ThreadLocalRandom.current() .nextInt(4, 77);
- 51. Designing Objects for Concurrency Patterns for safely representing and managing state Immutability • Avoiding interference by avoiding change Locking • Guaranteeing exclusive access State dependence • What to do when you can’t do anything Containment • Hiding internal objects Splitting • Separating independent aspects of objects and locks