Why we need Threads?
- Responsiveness - can be achieved with Concurrency (Multitasking)
- Performance - can be achieved with Parallelism
Context Switching
- Context switching is expensive
- Context switching between threads is a lot cheaper than context switching between processes
- Too many threads - OS spending more time in management than real productive work
- Thread consuming less resources than processes.
Thread scheduling
- There are different possible of ways to schedule
- First Come First Serve - problem with that if long threads come first other thread will be unresponsiveness, it is called starvation
- Short Job First - this time longest job will wait
- Epochs - OS divides CPU time to moderately sized pieces called Epochs. OS allocates different time for each thread in each Epoch. It is done according to Dynamic Priority calculations.
Thread creation & it's methods
- Two way of creating threads
- Implement Runnable interface provide in construction of Thread object
- Extend Thread object
- Number of threads should be equal to number of cores in machines
- Use thread.setUncaughtExceptionHandler to catch unchecked exceptions during run-time.
You can either clean up resources or log the issue for trouble shooting purposes - Stopping thread from another thread has two ways
- Thread.interrupt() - you can interrupt the thread in two scenarios
- If the thread is executing a method that throws an InterruptedException
- If the thread code is handing the interrupt signal explicitly
- Daemon threads - background threads that do not prevent the application from exiting if the main thread terminates. Other reason , code in a worked thread is not under our control, and we do not want it to block our application from terminating
- By default, at least if one thread is running application will not stop even main thread stopped. So we need to stop all threads gracefully
- Thread.join()
- calling the join() method has a synchronization effect. join() creates a happens-before relationship
- Happens-before : This means that when a thread t1 calls t2.join(), then all changes done by t2 are visible in t1 on return. However, if we do not invoke join() or use other synchronization mechanisms, we do not have any guarantee that changes in the other thread will be visible to the current thread even if the other thread has completed.
- When we invoke the join() method on a thread, the calling thread goes into a waiting state. It remains in a waiting state until the referenced thread terminates.
- Timed join() is dependent on the OS for timing. So, we cannot assume that join() will wait exactly as long as specified.
- In order to avoid creation/destroy of threads there is thread pooling mechanisms.
Data Sharing between Threads
- Thread local variables are stored in stack . Like local variable and local object references
- Shared information stored in Heap. Like Objects, class members and static variables
- Critical section guarded with synchronized keyword. Two ways of doing this
- synchronized on method level - Monitor
- synchronized inside method with explicit object - lock
- Re-entrant - thread in synchronized method/section can access to other synchronized method/section
Atomic Operations
- Object reference assignment - including getter, setter for exmaple
- Primitive type assignments except long and double. Because long and double 64 bit long
- We can define long and double volatile. With volatile they are guaranteed in single HW operation
- Knowledge of atomic operations is key to us create high performance applications
Concurrency problems
- Race condition : two threads working on same shared object. One of them modifying the object , due to OS scheduling it may cause incorrect results. Core of the problem is non-atomic operation performed on shared object . Solution - identifying the critical section where race condition happened and protecting with synchronized block.
https://stackoverflow.com/questions/34510/what-is-a-race-condition - Data race : solution, establish happens-before semantics by one of these methods
- synchronization of method
- using volatile. No compiler re-ordering will happen. whatever code before and after volatile will run as is.
Locking Strategies
- Coarse-grained strategy : lock whole object. Might impact the performance
- Fine-grained strategy : lock party of shared objects using lock object
Deadlock
- Condition to leads to deadlock
- Mutual exclusion
- Hold and wait
- Non-preemptive allocation
- Circular wait
- Solution to deadlock is avoid one the conditions mentioned above
- Avoid circular wait - this one easiest one.
- Deadlock detection
- Watchdog
- Thread interruption
- tryLock operation
Reentrant Lock
- Similar locking with synchronized locking but provides more control over lock with advanced operations
- Pattern to use itclass SharedData{private Lock lockObject = new ReenterantLock();public void method(){lockObject.lock();try{userSharedObject();}finally(){lockObject.unlock();}}}
- In order to avoid starvation - one thread is continuously using shared object but other are waiting - you can set true into constructor of ReenterantLock(true) object. which is fairness flag. But this one comes with cost. Use only when you really need it.
- ReenterantLock.lockInterrupility()
- ReenterantLock.tryLock()
- ReenterantReadWriteLock - if our shared object is read intensive we can use it otherwise it can perform worse then traditional locks. Example of using read-write lock is caching where system is read intensive. Multiple read threads can access the shared object and lock it, we can see number of concurrent read threads. Only one write thread can lock the shared object no other write/read threads can access during write lock.
Semaphore
- Can restrict number of threads accessing to shared data.
- similar to lock but different in many ways.
- One use case if Producer-Consumer using semaphore. Producer-consumer pattern used in web sockets, video streaming, Actor models
Condition variable
Other methods
- wait
- notify() and notifyAll()
Lock free programming
- AtomicInteger, AtomicLong...
- AtomicReferences
