Core Java Advanced LiveLessons

Concurrent Programming

Slide navigation: Forward with space bar, → arrow key, or PgDn. Backwards with ← or PgUp.

Use executors to run tasks concurrently

Running Tasks

• The Runnable interface describes a task that you want to run, usually concurrently with others:

  public interface Runnable {
      void run();
  }

• The code in the run method is run in a thread.
  • Threads are supplied by the operating system.
  • Multiple threads can run concurrently on different cores or time slices on the same core.
• Not a good idea to run each task on a different thread.
  • Thread creation and context switches are not free.
  • Optimal management depends on the nature of the tasks.
• Use an executor to execute tasks.

Executors

• Use this code outline for executing a task:

  Runnable task = () -> { ... };
  Executor exec = ...;
  exec.execute(task);

• The Executors has factory methods for making executors:

  Executor exec = Executors.newCachedThreadPool();
      // Good for many short-lived tasks
  int processors = Runtime.getRuntime().availableProcessors();
  int nthreads = processors - 2;
  
  Executor exec = Executors.newFixedThreadPool(nthreads);
      // Good for computationally intensive tasks
     
  

Running Tasks Concurrently

• Run two tasks concurrently:

  Runnable hellos = () -> {
      for (int i = 1; i <= 1000; i++) System.out.println("Hello " + i);
  };
  Runnable goodbyes = () -> {
      for (int i = 1; i <= 1000; i++) System.out.println("Goodbye " + i);
  };
  Executor executor = Executors.newCachedThreadPool();
  executor.execute(hellos);
  executor.execute(goodbyes);

• Outputs are interleaved:

  Goodbye 1
  ...
  Goodbye 871
  Goodbye 872
  Hello 806
  Hello 807
  Goodbye 882
  ...
  Hello 1000

lesson04/runnable

Callables

• Consider a computation that is split into tasks.
• The results of all tasks are combined for the final result.
• Unlike Runnable, a Callable yields a result:

  public interface Callable<V> {
      V call() throws Exception;
  }

• Need ExecutorService to execute a Callable:

  ExecutorService exec = Executors.newFixedThreadPool();
  Callable<V> task = ...;
  Future<V> result = exec.submit(task);

• The result is a future—an object that represents a computation whose result will be available at some future time.

Futures

• The Future interface has these methods:

  V get() throws InterruptedException, ExecutionException
  V get(long timeout, TimeUnit unit)
      throws InterruptedException, ExecutionException, TimeoutException;
  boolean isDone()
  boolean cancel(boolean mayInterruptIfRunning)
  boolean isCancelled()

• A call to get blocks until the result is available.
• Usually better to block until all tasks are done:

  Set<Path> paths = ...;
  List<Callable<Long>> tasks = new ArrayList<>();
  for (Path p : paths) tasks.add(
      () -> { return some value derived from contents of p });
  List<Future<Long>> results = executor.invokeAll(tasks);
  for (Future<Long> result : results) Process result.get();

More about Executor Services

• To avoid waiting for all tasks to complete, use an ExecutorCompletionService which returns futures in order of completion:

  ExecutorCompletionService service = new ExecutorCompletionService(executor);
  for (Callable<T> task : tasks) service.submit(task);
  for (int i = 0; i < tasks.size(); i++) {
      Process service.take().get()
      Do something else
  }
  

• To stop after the first result becomes available, use the invokeAny method:

  List<Callable<Path>> tasks = new ArrayList<>();
  for (Path p : files) tasks.add(
      () -> { if (word occurs in p) return p; else throw ... });
  Path found = executor.invokeAny(tasks);

• As soon as a result is found, the other tasks are canceled.

lesson04/callable

Understand the risks of concurrent execution

Concurrency—What Could Possibly Go Wrong?

• Concurrent programming is incredibly hard.
• Multiple threads can access the same resources in parallel.
• Data can be corrupted in multiple ways.
• Bugs are nondeterministic.
  • “But it works on my machine!”
• Step 1: Understand what can go wrong.
• Step 2: Understand what you can do to avoid problems.

Sharing Variables

• Reading and writing a variable is complex on modern hardware.
• Consider two threads accessing the same variable:

  private static boolean done = false;
  Runnable hellos = () -> {
      for (int i = 1; i <= 1000; i++) System.out.println("Hello " + i);
      done = true;
  };
  Runnable goodbye = () -> {
      int i = 1;
      while (!done) i++;
      System.out.println("Goodbye " + i);
  };

• When run concurrently, we expect 1000 hellos and one goodbye.
• On my laptop, I get 1000 hellos but no goodbye.
• Why?

lesson04/visibility

Visibility

• The effect of done = true; in one thread is not visible to the other thread!
• Lack of visibility can be caused by caching.
  • RAM is slow, so each processor caches recently accessed variables.
  • By default, caches are not synchronized.
• Lack of visibility can be caused by instruction reordering.
  • Compiler and processor can reorder instructions to speed up operations.
  • The loop

    while (!done) i++;

    can be reordered as

    if (!done) while (true) i++;

  • By default, optimization assumes that variables don't change “out of the blue”.

Ensuring Visibiliity

• Four ways of ensuring visibility:
  1. A final variable is visible after initialization.
  2. The initial value of a static variable is visible after initialization.
  3. Changes to a volatile variable are visible.
  4. Changes that happen before releasing a lock are visible to anyone acquiring the same lock. (We'll talk about locks soon.)
• In our case, we can fix the problem by declaring:

  private static volatile boolean done;
  

• The final modifier is your friend. Use it when appropriate for all fields.

Race Conditions

• Suppose concurrent tasks update a shared counter:

  private static volatile int count = 0;
  ...
  count++; // Task 1
  ...
  count++; // Task 2
  ...

• The update count++ is not atomic.
• An increment consists of multiple operations:

  register = count;
  Increment register
  count = register;

• If execution is interrupted before storing the incremented value, an increment can be lost:

  register1 = count;
  Increment register1
  register2 = count;
  Increment register2
  count = register2;
  count = register1;
  

lesson04/raceCondition/RaceConditionDemo

Race Conditions

• How likely is such an unlucky execution sequence?
  • On modern hardware, surprisingly often.
  • Debugging is even worse when it happens rarely.
• Shared counters are far from the only problem.
• Consider adding a value to a queue that is implemented as a linked list:

  Node n = new Node();
  if (head == null) head = n;
  else tail.next = n;
  tail = n;
  tail.value = newValue;

• If two threads interleave these operations, the data structure can get damaged!

lesson04/raceCondition/RaceConditionDemo2

Strategies for Safe Concurrency

• Unfortunately, no equivalent to garbage collection for safe concurrency.
• Strategy: confinement.
  • Don't share data among tasks.
  • Example: Each task has its own counter, and the counts are combined after the tasks finish.
• Strategy: immutability.
  • It is safe to share immutable data structures.
  • How can you get any work done when nothing can be mutated?
  • Tasks can combine results from other tasks into immutable data structures.
• Strategy: locking.
  • Temporarily block other tasks when carrying out updates.
  • Can be expensive—other tasks wait idly.
  • Can be dangerous—deadlocks and subtle programming errors.
  • Best left to experts.

Immutable Classes

• Class is immutable if instance can't change after construction.
• Examples: String, java.time.ZonedDateTime
• Consider collecting results in a set.
• Using HashSet for aggregating results is dangerous:

  results.addAll(newResult); // What if another thread accesses results?
  

• The addAll operation is complex and must be atomic.
• With an immutable set (not in the Java API), you can update like this:

  results = results.union(newResult);
  

• Now there is only one mutation that must be controlled.

Implementing Immutable Classes

• Be sure to declare instance variables final.
  • The VM guarantees visibility.
• Of course, none of the methods can be mutators.
  • Consider declaring all methods, or the class, as final.
• Don't leak mutable state.
  • Don't have any method return a reference to any mutable innards such as arrays.
  • Don't pass any such references to other methods.
• Don't let this escape in a constructor.
  • Someone could observe a partially constructed object.
  • Don't pass this to another method during construction.
  • Don't let this be captured in an inner class during construction.

Use the Java API for parallel algorithms

Parallel Streams

• Before parallelizing your algorithms, check if the API has done it already.
• Use parallel streams if you work on large in-memory data:

  long result = coll.parallelStream()
      .filter(s -> s.startsWith("A")).count();

• Of course, your lambdas need to be threadsafe.
• Be very careful when work in your lambdas might block:

  urls.parallelStream().map(url -> Read contents of url)...
      // Problematic——might starve global fork-join pool.
  

Parallel Arrays

• The Arrays class has several methods that are parallelized for you.
• You can sort arrays of objects or primitive types:

  Arrays.parallelSort(words, Comparator.comparing(String::length));

• Don't mutate or block in the comparator!
• Filling an array works concurrently on multiple segments:

  Arrays.parallelSetAll(values, i -> i % 10);

• Otherwise, you can use stream operations:

  long sum = IntStream.of(values).parallel().sum();

jshell

void time(Runnable task) {
    long start = System.nanoTime();
    task.run();
    long end = System.nanoTime();
    System.out.println((end - start) * 1E-9 + " seconds");
}
int SIZE = 100_000_000;
int[] values = new int[SIZE];
Arrays.parallelSetAll(values, i -> (int) (SIZE * Math.sin(i)));
time(() -> Arrays.parallelSort(values));
Arrays.parallelSetAll(values, i -> (int) (SIZE * Math.sin(i)));
time(() -> Arrays.sort(values));

Use the threadsafe data structures in the Java API

Concurrent Hash Maps

• The java.util.concurrent package supplies ConcurrentHashMap and other concurrent data structures.
• Safe to mutate concurrently.
• Clever implementations allow simultaneous updates in different parts of the hash table.
  • Don't try implementing this at home!
• Iterators are “weaky consistent”.
  • Elements present at the onset of the iteration are presented.
  • Later modifications may or may not be reflected.
  • No ConcurrentModificationException

Working with Concurrent Hash Maps

• ConcurrentHashMap won't be damaged by concurrent mutations.
• That doesn't mean that your algorithms are threadsafe:

  Long oldValue = map.get(word);
  Long newValue = oldValue == null ? 1 : oldValue + 1;
  map.put(word, newValue); // Error—might not replace oldValue

• Use methods for atomic updates:

  map.compute(word, (k, v) -> v == null ? 1 : v + 1);

• Variants computeIfPresent, computeIfAbsent
• Use putIfAbsent to atomically initialize a value:

  map.putIfAbsent(word, 0L);
  

• The merge method lets you supply an initial key and an update operation:

  map.merge(word, 1L, (existingValue, newValue) -> existingValue + newValue);
      // Or simply map.merge(word, 1L, Long::sum);

• Lambdas should complete quickly and not mutate the map!
• Bulk operations forEach, reduce, search, replaceAll

concurrentHashMap

Blocking Queues

• ArrayBlockingQueue and LinkedBlockingQueue are threadsafe implementations of bounded queues.
• The add/remove methods throw an IllegalStateException when queue is full/empty.
• The put/take methods block when queue is full/empty.
• The offer/poll methods return false/null when queue is full/empty.
  • Optionally with timeout:

    boolean success = q.offer(x, 100, TimeUnit.MILLISECONDS);

• Convenient for producer/consumer scenarios.
  • Producer threads put partial results into the queue.
  • Consumers remove partial results and work on them.
  • With bounded queue, producers block until consumers catch up.
  • Signal end of production with “last bag” result.

blockingQueue

Work with atomic values

Atomic Values

• API has classes for safe concurrent updates of integers, long and boolean values, object references, and arrays of these values.
• Atomic counters and accumulators are useful for application programmers.
• The others are meant for experts.
• Generate a sequence of numbers:

  public static AtomicLong nextNumber = new AtomicLong();
  // In some thread . . .
  long id = nextNumber.incrementAndGet();

Working with Atomic Values

• Accumulate a sum from partial sums:

  public static AtomicLong sum = new AtomicLong();
  // In some thread . . .
  sum.addAndGet(partialSum);

• Beware of non-atomic updates:

  public static AtomicLong largest = new AtomicLong();
  // In some thread . . .
  largest.set(Math.max(largest.get(), observed)); // Error—race condition!

• Instead, use updateAndGet or accumulateAndGet:

  largest.updateAndGet(x -> Math.max(x, observed));
  largest.accumulateAndGet(observed, Math::max);

Working with Accumulators

• Updates of AtomicLong can be inefficient under high contention.
  • Updates are optimistic: new value is computed and set, provided the old value hasn't been changed in the meantime.
  • When many threads change the value, the compute-and-set needs to be retried often.
• The LongAccumulator class solves this problem by splitting a counter or accumulator into multiple variables:

  LongAccumulator accumulator = new LongAccumulator(Long::max, 0);
  // In some tasks . . .
  accumulator.accumulate(value);
  // When all work is done
  long largest = accumulator.get();

• There is also a LongAdder if you just need a counter.

atomic

Become familiar with low-level locks

Locks

• Locks are low-level constructs for limiting access to a single thread.
• Useful for building threadsafe data structures such as concurrent maps or blocking queues.
• Not intended for application programmers.
• But application programmers should have an understanding of the costs and complexities.

Reentrant Locks

• A reentrant lock can ensure that a code segment (called a critical section) is executed in its entirety.
• Call lock before entering the critical section and unlock when leaving it:

  Lock countLock = new ReentrantLock(); // Shared among multiple threads
  int count; // Shared among multiple threads
  ...
  countLock.lock();
  try {
      count++; // Critical section
  } finally {
      countLock.unlock(); // Make sure the lock is unlocked
  }

• Seems straightforward, but the devil is in the details.

Intrinsic Locks

• Instead of using explicit ReentrantLock, you can use intrinsic locks.
• Every object has a lock.
• The synchronized statement locks and unlocks the intrinsic lock:

  synchronized(obj) {
     Critical section
  }
  

• Equivalent to:

  obj.intrinsicLock.lock();
  try {
      Critical section
  } finally {
      obj.intrinsicLock.unlock();
  }

Synchronized Methods

• Declaring a method as synchronized locks the body on this:

  public synchronized void method() { body }

• Equivalent to:

  public void method() {
      synchronized(this) { body }
  }

• For example, here is a threadsafe Counter class:

  public class Counter {
      private int value;
      public synchronized int increment() {
          value++;
          return value;
      }
  }

• Variable changes in a critical section that is protected by locks are guaranteed to be visible to other threads.

The Monitor Concept

• In the 1970s, Per Brinch Hansen and Tony Hoare pioneered the concept of threadsafe data structures that they called monitors.
  • In a monitor, all instance variables are private.
  • All methods are protected by a private lock.
• In Java, you can mix public/private variables and synchronized/unsynchronized methods.
• In Java, the intrinsic lock is public:

  synchronized (table) {
      for (K key : table.keySet()) ...
  }

• Common source of confusion/errors:

  synchronized ("LOCK") {
      for (K key : table.keySet()) ...
  }

Conditions

• Locks are not enough to implement threadsafe data structures.
• Blocking methods need to be able to wait:

  public synchronized Object take() { // From a blocking queue 
      if (head == null) ...; // Can't proceed
      Node n = head;
      head = n.next;
      return n.value;
  }

• But they can't wait while holding the lock.
  • Otherwise, no other thread can add to the queue.
• Calling wait makes thread relinquish lock and enter a “waiting” state:

  public synchronized Object take() { // From a blocking queue 
      while (head == null) wait();
      ...
  }

• Some other thread should call notifyAll to allow waiting threads to continue:

  public synchronized void add(Object newValue) {
      ...
      notifyAll();
  }
  

lesson04/locks/QueueDemo.java

Understand the characteristics of Java threads

Threads

• Generally, run tasks with executors.
• Starting a thread directly is useful for test/demo programs.
• Construct a thread and start it:

  Runnable task = () -> { ... };
  Thread thread = new Thread(task);
  thread.start();

• To put the current thread to sleep, call:

  Thread.sleep(milliseconds);

• Thread ends when run method ends (normally or due to an exception).
• The current thread can wait for another thread to complete:

  thread.join(milliseconds);
  

Interrupting Threads

• Stopping a thread is unsafe and deprecated.
  • If a thread holds a lock, the lock will never be released.
• Instead, use the cooperative interruption mechanism.
• A thread can interrupt another thread:

  thread.interrupt();
  

• That simply sets the “interrupted” flag of the thread.
• Threads that agree to be interrupted should check for interruption at opportune moments:

  while (more work to do) {
      if (Thread.currentThread().isInterrupted()) return;
      Do more work
  }

• Usually, threads exit safely when they are interrupted.

The InterruptedException

• When a thread waits or sleeps while it is interrupted, the “interrupted” flag is not set.
• Instead, an InterruptedException is thrown.
• If an interrupted thread just want to exit, catch the exception at the outermost level:

  try {
      while (more work to do) {
          Do more work
          Thread.sleep(millis);
      }
  }
  catch (InterruptedException ex) {
      // Do nothing
  }

• You need not call isInterrupted.
  • sleep throws an InterruptedException when it is called from an interrupted thread.

lesson04/interruption

Thread-Local Variables

• Can avoid sharing by confining variables to a thread.
• NumberFormat is not threadsafe and should not be globally shared.
• Wasteful to use synchronization, or to create a new instance before each use.
• It is safe to share a NumberFormat instance for each thread.
• Use thread-local storage:

  public static final ThreadLocal<NumberFormat> currencyFormat =
      ThreadLocal.withInitial(() -> NumberFormat.getCurrencyInstance());

• To access the formatter, call:

  String amountDue = currencyFormat.get().format(total);

• The first time you call get in a given thread, the lambda in withInitial is called.

lesson04/threadLocal

Miscellaneous Thread Properties

• Threads can be collected in thread groups, and you can control all threads in a group together.
  • Prefer using executors for managing task groups.
• Threads can have priorities.
  • High priority threads execute before low priority threads.
  • Details are platform-dependent.
• Threads have states: new, running, blocked on I/O, waiting, terminated.
  • Not generally useful for application programmers.
• Each thread has a handler for uncaught exceptions.
  • By default, its stack trace is dumped to System.err
  • Can provide a different handler, typically for logging.
• A daemon is a thread that serves others, e.g. for timer ticks or cache cleanup.
  • When only daemon threads remain, the VM exits.
  • Call thread.setDaemon(true) before starting the thread.

Organize asynchronous computations

Long-Running Tasks in UI Callbacks

• One reason for using threads is to make programs more responsive.
• User interface shouldn't freeze during time-consuming operations.
• Don't do this:

  JButton read = new JButton("Read");
  read.addActionListener(event -> Read document from url);

• Instead, do the work in a separate thread:

  read.addActionListener(event -> Start new task that reads document from url);
  

• UI is not threadsafe.
  • New thread can't update the UI.
  • Instead, use mechanism for asynchronous UI update:

    EventQueue.invokeLater(() -> Update UI for progress or completion display);
    

• Toolkits such as Swing/Android have classes SwingWorker/AsyncTask to manage event flow.

SwingWorker

Completable Futures

• When a task should not block, we run it in a separate thread.
• When the task has completed, we usually want to move on to the next step.
• Can specify an event handler that is called on completion.
• But what if the next action is also asynchronous?
• And what if we have normal paths and error paths?
• This leads to “callback hell”.
• CompletableFuture class provides an alternative.
• A CompletableFuture<T> is a Future<T> which will deliver a value at some point in the future.
• A CompletableFuture<T> implements the CompletionStage<T> interface, which allows completable futures to be composed.

Working with Completable Futures

• Turn your processing pipeline into a sequence of methods. When a method is time-consuming, make it return a CompletableFuture:

  public CompletableFuture<String> readPage(URL url)
  public List<URL> getImageURLs(String webpage) // Not time-consuming
  public CompletableFuture<List<BufferedImage>> getImages(List<URL> urls)
  public void saveImages(List<BufferedImage> images)
  

• Now you can compose the operations:

  CompletableFuture.completedFuture(urlToProcess)
      .thenComposeAsync(this::readPage, executor)
      .thenApply(this::getImageURLs)
      .thenCompose(this::getImages)
      .thenAccept(this::saveImages);
  

Dealing with Errors

• When any of the steps in the pipeline throws an exception, processing terminates with a CompletionException that wraps the original exception.
• The exceptionally method allows you to substitute a value for an exception:

  CompletableFuture.completedFuture(urlToProcess)
      .thenComposeAsync(this::readPage, executor)
      .exceptionally(ex -> "<html></html>")
      .thenApply(this::getImageURLs)
  

• You can add arbitrary post-processing to a stage by calling handle with a BiFunction<T, Throwable, U> that receives either the result or the exception (and null for the other).

Combining Results

• You can run two computations in parallel and then combine their results:

  CompletableFuture<T> future1 = ...;
  CompletableFuture<U> future2 = ...;
  CompletableFuture<V> combined = future1.thenCombine(future2, combiner);
  

• Here, combiner is a function taking arguments of type T and U, and producing a result of type V.
• The static CompletableFuture.allOf method takes an array or varargs sequence of completable futures and waits for all of them to complete, but it doesn't combine the results.
• If you are happy with either of the two results, use the applyToEither method:

  CompletableFuture<T> future1 = ...;
  CompletableFuture<T> future2 = ...;
  CompletableFuture<U> combined = future1.applyToEither(future2, f);
      // f maps T to U
  

• The other future is not automatically canceled.

completableFutures

Java 9 News Flash - Completable Futures

• Java 9 adds support for timeouts.
• Substitute another result on timeout:

  CompletableFuture.completedFuture(urlToProcess)
      .thenComposeAsync(this::readPage, executor)
      .completeOnTimeout("<html></html>", 30, TimeUnit.SECONDS)
      .thenApply(this::getImageURLs)
      ...
  

• Fail on timeout:

  CompletableFuture.completedFuture(urlToProcess)
      .thenComposeAsync(this::readPage, executor)
      .orTimeout(30, TimeUnit.SECONDS)
      .thenApply(this::getImageURLs)
      ...
  

Run operating system processes

Executing a Process from a Java Program

• An operating system process runs separately from the process that runs the Java virtual machine.
• Communicate through standard input, standard output, standard error streams.
• Use ProcessBuilder to construct a Process object.
• Run the process:
  • Start the process.
  • Feed input to the process.
  • Read output and errors from the process.
  • Wait for the process to complete.

Building a Process with the ProcessBuilder Class

• Supply the strings that make the command:

  ProcessBuilder builder = new ProcessBuilder("gcc", "myapp.c");
      // You can also provide a List<String>

• Set the working directory:

  builder = builder.directory(path.toFile());

• Set any environment variables:

  Map<String, String> env = builder.environment();
  env.put("LANG", "fr_FR");
  env.remove("JAVA_HOME");

The Input, Output, and Error Streams

• Choices for setting the input, output, and error streams of the process:
  1. Read and write as the process runs (the default).
  2. Redirect the streams of the JVM process to your process.
  3. Redirect to files.
• To redirect the JVM streams to your process, call:

  builder.redirectIO()

• To redirect to files, call:

  builder.redirectInput(inputFile)
      .redirectOutput(outputFile)
      .redirectError(errorFile)

• You can also merge the error stream to the output stream:

  builder.redirectErrorStream(true)

Running the Process

• To start the process, call:

  Process p = builder.start();

• If you elected not to redirect the input, output, and error streams, get Java input/output streams for the process streams:

  OutputStream processIn = p.getOutputStream();
  InputStream processOut = p.getInputStream();
  InputStream processErr = p.getErrorStream();

• Write the process input to processIn, and read the output and errors from processOut and processErr.
• Note that processIn is an OutputStream since your Java program writes to it and the process reads what your program wrote.
• Then wait for the process to finish:

  int result = p.waitFor()
  int result = p.waitFor(delay, TimeUnit.SECONDS);
  

• If you need to kill the process, call:

  p.destroy(); // SIGTERM in Unix
  p.destroyForcibly();  // SIGKILL in Unix
  

jshell

import java.io.*;
ProcessBuilder builder = new ProcessBuilder("ls", "-al");
Process p = builder.directory(new File("/home/cay")).start();
InputStream processOut = p.getInputStream();
Scanner in = new Scanner(processOut);
while (in.hasNextLine()) System.out.println(in.nextLine());
p.waitFor()

Java 9 News Flash - Process Improvements

• The onExit method yields a CompletableFuture<ProcessHandle> that completes when the process is completed:

  Process process = new ProcessBuilder("/bin/ls").start();
  process.onExit().thenAccept(h -> System.out.println(h + " all done"));
  

Process Handles

• Get ProcessHandle by calling:
  • proc.toHandle() from a Process process
  • ProcessHandle.of(pid) with an OS PID
  • ProcessHandle.current()
  • ProcessHandle.allProcesses()
• Get OS process information:

  long pid = handle.pid();
  Optional<ProcessHandle> parent = handle.parent();
  Stream<ProcessHandle> children = handle.children();
  Stream<ProcessHandle> descendants = handle.descendants();
  ProcessHandle.Info info = handle.info();
  

• ProcessHandle.info yields command/commandLine/arguments/startInstant/totalCpuDuration/user if available.