Luis Enrique León's List: Java

• block-structured concurrency. This was the only  game in town prior to Java 5, and it’s still worth understanding.
• Next, we’ll cover what every working developer should know  about java.util.concurrent and how to use the basic concurrency building blocks it provides.
• you’ll  need to know more than we can cover here if you’re going to be a truly first-rate developer of multithreaded code.

• Java’s threading model is based on two fundamental concepts:

     
   
  • Shared, visible-by-default mutable state   
     
  • Preemptive thread scheduling
• • Methods must be able to be swapped out while they’re running (otherwise a method with an infinite loop would steal the CPU  forever).  This, however, runs the risk of an unpredictable thread swap leaving a method “half-done” and an object in an inconsistent  state. There is also the risk of changes made in one thread not being visible in other threads when they need to be. To mitigate  these risks, we come to the last point.   
     
  • Objects can be locked to protect vulnerable data.
• Java’s thread- and lock-based concurrency is very low-level, and often hard to work with. To cope with this, a set of concurrency  libraries, known as java.util.concurrent, was introduced in Java 5. This provided a set of tools for writing concurrent code that many programmers find easier to  use than the classic block-structured concurrency primitives.

• The most important design forces were catalogued by Doug Lea as he was doing his landmark work producing java.util.concurrent: 

     
   
  • Safety (also known as concurrent type safety)   
     
  • Liveness   
     
  • Performance   
     
  • Reusability   
• Staying safe   

  One strategy for safety is to never return from a non-private method in an inconsistent state, and to never call any non-private  method (and certainly not a method on any other object) while in an inconsistent state. If this is combined with a way of  protecting the object (such as a synchronization lock or critical section) while it’s inconsistent, the system can be guaranteed  to be safe. 
• Safety stands in opposition to liveness—safety is about ensuring that bad things don’t happen, whereas liveness requires progress  to be made.
• Reusable systems tend to expose their internals, which can cause problems with safety.
• A naïvely written safe system will typically not be very performant, as it usually resorts to the heavy use of locking to  provide safety guarantees.

• There are many aspects of a concurrent system that can contribute to the inherent overhead:

     
   
  • Locks and monitors   
     
  • Number of context switches   
     
  • Number of threads   
     
  • Scheduling   
     
  • Locality of memory   
     
  • Algorithm design   
     

  This should form the basis of a checklist in your mind. When developing concurrent code, you should ensure that you have thought  about everything on this list, before considering the code “done.” 
• Designs of this type are very well-suited to being implemented using the classes found in java.util.concurrent. The package contains thread pools for execution (and a nice set of factory methods in the Executors class to create them) and queues for handing work off between pools. There are also concurrent data structures (for building  shared caches and other use cases) and many other useful low-level tools.
• to get the most out of the discussion of the alternatives, it’s important to have a firm grasp of what’s good and bad  about the classic view of concurrency.
• As you already know, the synchronized keyword can be applied either to a block or to a method. It indicates that before entering the block or method, a thread  must acquire the appropriate lock.
• Only one thread can be progressing through any of an object’s synchronized blocks or methods at once; if other threads try  to enter, they’re suspended by the JVM. This is true regardless of whether the other thread is trying to enter either the  same or a different synchronized block on the same object. In concurrency theory, this type of construct is referred to as  a critical section.
• The thread can be blocked because it’s waiting on I/O or to acquire a lock held by another thread. In this case, the thread  isn’t swapped off the core but is kept busy, waiting for the lock or data to become available. If this happens, the thread  will continue to execute until the end of its timeslice.
• This seems fantastic at first glance—the class is both safe and live. The problem comes with performance—just because something  is safe and live doesn’t mean it’s necessarily going to be very quick. You have to use synchronized to coordinate all the accesses (both get and put) to the arrivalTime map, and that locking is ultimately going to slow you down. This is a central problem of this way of handling concurrency.

16 more annotations...

• The two strategies for scheduling threads on the CPU are preemptive and nonpreemptive scheduling. In case of preemptive scheduling, a thread with a higher priority (the moment it is created or acquires a higher priority) will preempt the running thread and acquire the CPU for execution. A preemptive scheduling scheme may also use time slicing, whereby threads at the same priority level will be allocated the CPU for a maximum of a certain fixed time interval. Windows NT is an example of a preemptive OS.
• In case of nonpreemptive scheduling, a running thread continues using CPU cycles even if a thread with a higher priority exists. Thus, a running thread may be required to relinquish the CPU voluntarily so that other threads get a chance to execute. In this scheme, a badly written program can lock up your OS (a system hang-up). Nonpreemptive scheduling may also be time-sliced, where the user may decide the amount of time for the slice. For example, Windows 3.1 is a nonpreemptive OS,