Lecture 13: Concurrency Abstractions

Lecture 13 (given 22nd February): further concurrency control and abstraction mechanisms provided in Java. Data abstraction: ensuring consistency by using library classes for atomic actions or thread-safe datatypes such as concurrent collections. Why these are still not enough . Control abstractions: fine-grained parallelism by decomposing processes into threads, then threads into tasks. Executors in Java. Callables and futures.

Link: Slides.

Homework

You should explore Java concurrency mechanisms in more detail, in particular, using some of the facilities provided by the java.util.concurrent packages.

  • Experiment with a program that exhibits a race condition, and make sure you can fix it in the ways described in the lecture slides.
  • Modify the Pigeon Fancier program you wrote earlier to use the executor framework and allow for dynamic reconfiguration of the pigeon coop.
  • Investigate some of the explicit locking facilities provided in java.util.concurrent and make sure you can explain situations when these might be needed.

See the lecture slides for more detail. Please post questions and discussion here and we’ll follow up.

One Response to Lecture 13: Concurrency Abstractions

  1. Hugh C-B says:

    I made a small modification to my code for the PigeonFancier to use the executor framework, which can be seen at http://sigmaris.info/trac/browser/PigeonFancier/src/pigeon/PigeonFancier2.java

    I then experimented with converting PigeonEmptier and PigeonStuffer to be single-shot tasks which could then be run at determined intervals by a ScheduledExecutorService. This code can bee seen at http://sigmaris.info/trac/browser/PigeonFancier/src/scheduledpigeon

    While converting the tasks I ran into a problem – If I set the core thread count for the executor to less than the number of emptier tasks, the system would eventually deadlock when all the threads of the executor were running emptier tasks which were all wait()ing for empty pigeonholes to be full, while the stuffer task would never run. I got around this by using a separate executor for the stuffer task.

    It appears that the ScheduledThreadPoolExecutor uses a fixed size pool of threads, and will not create new threads to run a scheduled task even if all its existing threads are blocked.