Please enable JavaScript.

Coggle requires JavaScript to display documents.

Concurrency & Threading (Producer/Consumer (BlockingQueue vs…

- - - - when we call start() method Java Virtual machine execute run() method of that Thread class it goes into RUNNBLE state.
      - difference between start vs run in Java is that you can not call start() method twice on thread object. once started, second call of start() will throw IllegalStateException in Java while you can call run() method twice.
    - - what will happen if we call the run() method directly instead of calling start() method ? There would be no Error or Exception, run() method will simply be executed in the same Thread and new Thread will not be created.
  - - - state after creation, before running thread.start()
    - - after calling start(), while executing
      - BLOCKED
        
        waiting at the entrance of a synchronized block
      - WAITING
        
        a thread enters this state if it waits for another thread to perform a particular action. For instance, a thread enters this state upon calling the Object.wait() method on a monitor it holds, or the Thread.join() method on another thread
      - TIMED_WAITING
        
        but a thread enters this state after calling timed versions of Thread.sleep(), Object.wait(), Thread.join() and some other methods a thread will be automatically notified after the time passes.
    - - a thread has completed the execution of its Runnable.run() method and terminated
      - Thread will be said to go on dead state once execution of run() method finished and you can not start that thread again.
    - - diagram
      - thread.getState() - returns the current state of the thread
- - - - private int count; /* * This method is not thread-safe because ++ is not an atomic operation */ public int getCount(){ return count++; }
      - solutions to make this atomic
        
        add synchronized keyword on method
        
        use AtomicInteger
        AtomicInteger atomicCount = new AtomicInteger( 0 ); public int getCountAtomically(){ return atomicCount.incrementAndGet(); }
- - - - is an interface and Java 5 provides different implantation like ArrayBlockingQueue and LinkedBlockingQueue, both implement FIFO order or elements, while Array is bounded in nature while Linked is optionally bounded.
    - - public class ProducerConsumerPattern { public static void main(String args[]){ //Creating shared object BlockingQueue sharedQueue = new LinkedBlockingQueue(); //Creating Producer and Consumer Thread Thread prodThread = new Thread(new Producer(sharedQueue)); Thread consThread = new Thread(new Consumer(sharedQueue)); //Starting producer and Consumer thread prodThread.start(); consThread.start(); }
      - class Consumer implements Runnable{ private final BlockingQueue sharedQueue; public Consumer (BlockingQueue sharedQueue) { this.sharedQueue = sharedQueue; } @Override public void run() { while(true){ try { System.out.println("Consumed: "+ sharedQueue.take()); } catch (InterruptedException ex) { // } } }
      - class Producer implements Runnable { private final BlockingQueue sharedQueue; public Producer(BlockingQueue sharedQueue) { this.sharedQueue = sharedQueue; } @Override public void run() { for(int i=0; i<10; i++){ try { System.out.println("Produced: " + i); sharedQueue.put(i); } catch (InterruptedException ex) { // } } } }
- - - - Shared State Can Get Complex
        
        shared workers often need access to some kind of shared data, either in memory or in a shared database
        
        The threads need to access the shared data in a way that makes sure that changes by one thread are visible to the others (pushed to main memory and not just stuck in the CPU cache of the CPU executing the thread)
      - Job Ordering is Nondeterministic
      - workers must re-read the state every time it needs it, to make sure it is working on the latest copy
  - - - Actor
        
        In the actor model each worker is called an actor. Actors can send messages directly to each other. Messages are sent and processed asynchronously. Actors can be used to implement one or more job processing assembly lines, as described earlier.
        
        Actor diagram
      - Channel
        
        In the channel model, workers do not communicate directly with each other. Instead they publish their messages (events) on different channels. Other workers can then listen for messages on these channels without the sender knowing who is listening.
        
        Channel diagram
    - - No Shared state
        
        The fact that workers share no state with other workers means that they can be implemented without having to think about all the concurrency problems that may arise from concurrent access to shared state. This makes it much easier to implement workers. You implement a worker as if it was the only thread performing that work - essentially a singlethreaded implementation.
      - Stateful Workers
        
        Since workers know that no other threads modify their data, the workers can be stateful. By stateful I mean that they can keep the data they need to operate in memory, only writing changes back the eventual external storage systems. A stateful worker can therefore often be faster than a stateless worker.
      - mechanical sympathy
        
        Singlethreaded code has the advantage that it often conforms better with how the underlying hardware works. First of all, you can usually create more optimized data structures and algorithms when you can assume the code is executed in single threaded mode.
        Second, singlethreaded stateful workers can cache data in memory as mentioned above. When data is cached in memory there is also a higher probability that this data is also cached in the CPU cache of the CPU executing the thread. This makes accessing cached data even faster.
      - Job Ordering is Possible
        
        It is possible to implement a concurrent system according to the assembly line concurrency model in a way that guarantees job ordering. Job ordering makes it much easier to reason about the state of a system at any given point in time. Furthermore, you could write all incoming jobs to a log. This log could then be used to rebuild the state of the system from scratch in case any part of the system fails. The jobs are written to the log in a certain order, and this order becomes the guaranteed job order. it greatly simplifies tasks like backup, restoring data, replicating data etc. as this can all be done via the log file(s).
    - - The main disadvantage of the assembly line concurrency model is that the execution of a job is often spread out over multiple workers, and thus over multiple classes in your project. Thus it becomes harder to see exactly what code is being executed for a given job.
      - It may also be harder to write the code. Worker code is sometimes written as callback handlers. Having code with many nested callback handlers may result in what some developer call callback hell. Callback hell simply means that it gets hard to track what the code is really doing across all the callbacks, as well as making sure that each callback has access to the data it needs.
        With the parallel worker concurrency model this tends to be easier. You can open the worker code and read the code executed pretty much from start to finish. Of course parallel worker code may also be spread over many different classes, but the execution sequence is often easier to read from the code.
- - - - ThreadPoolExecutor — for executing tasks using a pool of threads. Once a thread is finished executing the task, it goes back into the pool. If all threads in the pool are busy, then the task has to wait for its turn.
      - ScheduledThreadPoolExecutor allows to schedule task execution instead of running it immediately when a thread is available. It can also schedule tasks with fixed rate or fixed delay.
      - ForkJoinPool is a special ExecutorService for dealing with recursive algorithms tasks. If you use a regular ThreadPoolExecutor for a recursive algorithm, you will quickly find all your threads are busy waiting for the lower levels of recursion to finish. The ForkJoinPool implements the so-called work-stealing algorithm that allows it to use available threads more efficiently.