1. execution
1.1. implementing Runnable or Callable interface (run method)
1.1.1. passing as a parameter to Thread, run start()
1.1.1.1. object will be able to inherit another class
1.1.1.2. no unnecessary overhead as in case of extending Thread
1.2. extending the Thread class
1.2.1. overriding run()
2. terms
2.1. process
2.1.1. instance of a program in execution
2.1.1.1. has independent memory and CPU time allocated
2.1.2. has to use inter-process communications if wants to access other process' resources
2.1.2.1. pipes
2.1.2.1.1. files
2.2. thread
2.2.1. particular execution path of a process
2.2.2. share same heap
2.2.2.1. but have own registers and stack
2.2.3. can't start twice
2.2.3.1. will throw exception
2.2.4. run() method instead of start()?
2.2.4.1. will run just as object
2.2.5. interrupt()
2.2.6. types
2.2.6.1. Daemon thread
2.2.6.2. User thread
2.3. context switch
2.3.1. time spent switching between two processes
2.4. lock ownership
2.4.1. only the thread which locked the lock can unlock it
2.4.1.1. exception if you try otherwise
2.4.1.1.1. IllegalMonitorException
2.5. mutex or lock
2.5.1. ReentrantLock and synchronized
2.6. ThreadPool
2.7. preemptive scheduling and time slicing
2.8. shutdown hook
3. synchronization
3.1. mutual exclusive
3.1.1. synchronized methods
3.1.1.1. can be executed at the same if they are different instances of the same object
3.1.1.2. on the class lock
3.1.1.2.1. different sync methods of the same instance are not executed at the same time
3.1.1.3. static
3.1.1.3.1. if done on static method then applies to class not object
3.1.2. synchronized blocks
3.1.2.1. only one thread per instance can execute sync block
3.1.3. synchronized classes
3.2. cooperation
3.2.1. locks (=monitors, mutex)
3.2.1.1. used for more granular control
3.2.1.2. a thread gets access to a shared resource by first acquiring the lock associated with the resource
3.2.1.2.1. ReentrantLock()
3.2.2. semaphore
3.2.2.1. allows non-ownership-release semantics
3.3. states
3.3.1. diagram
3.3.2. join method
3.3.2.1. wait-notify
3.3.2.1.1. another ex
4. deadlock
4.1. occurs when (MiNCH)
4.1.1. Mutual exclusion
4.1.1.1. only one process can access a resource at a given time
4.1.1.2. if a resource has limited quantity
4.1.2. No Preemption
4.1.2.1. One process cannot forcibly remove another process' resource
4.1.3. Circular Wait
4.1.3.1. process forming a circular chain
4.1.3.2. most common to remove this condition to fix a deadlock
4.1.4. Hold and Wait
4.1.4.1. Processes already holding a resource can request more resource without relinquishing current resources
4.2. preventing
4.2.1. require a process to declare upfront what locks it will need
4.2.1.1. then check if deadlock will be created, fail if so