2

From Programming Language Pragmatics, by Scott

The fact that correctness depends on locking order means that lock-based program fragments do not compose: we cannot take existing lock-based abstractions and safely call them from within a new critical section.

What does "compose" mean?

Why do lock-based program fragments do not compose?

From Transform Java Future into a CompletableFuture

Java 8 introduces CompletableFuture, a new implementation of Future that is composable (includes a bunch of thenXxx methods). I'd like to use this exclusively, but many of the libraries I want to use return only non-composable Future instances.

What does it mean by some future instances are composable and some are not?

Thanks.

1 Answers1

0

For the first part, any lock-based thing is not trivial to compose. At the very least, to avoid dead-locks, you must define a lock order and use it everywhere. Also, a lock should be acquired for a really short time, so you should avoid locking around code that can block, such as long running operations or waiting on I/O.

For the second part, the Future<V> interface does not compose well because the only way to know when it finishes is through polling or blocking (isDone() and get()). You have no other way to be notified of the Future<V>'s completion.

There are specific futures that compose easily, such as CompletableFuture<V>, which allows you to be notified instead of polling or blocking.

However, if you get one of these as a Future<V>, you won't be able to take advantage of its notification mechanism. You can try casting to the CompletionStage<V> interface, which contains the composition methods.

acelent
  • 7,965
  • 21
  • 39