Concurrency without
explicit threads
•You can write concurrent applications that don’t
use explicit threads or synchronization
•Use built-in abstractions that support coordination
and parallel execution
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Concurrency without Explicit Threads - Notes | CMSC 132, Study notes of Computer Science
Material Type: Notes; Professor: Padua-Perez; Class: OBJECT-ORIENTED PROG II; Subject: Computer Science; University: University of Maryland; Term: Unknown 1989;
Typology: Study notes
Pre 2010
1 / 27
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Concurrency without Explicit Threads - Notes | CMSC 132 and more Study notes Computer Science in PDF only on Docsity!
Concurrency without
explicit threads
You can write concurrent applications that don’t use explicit threads or synchronization
Use built-in abstractions that support coordination and parallel execution
Key concepts
thread-safe collections
concurrent collections
blocking queues
synchronizers
thread locals
executors
Concurrent collections
Designed to allow multiple simultaneous accesses and updates
blocking only when they “conflict”
Higher space overhead
not much time overhead
Many of the concurrent collections do not allow null keys or values
ConcurrentHashMap
Allows simultaneous reads, and by default up to 16 simultaneous writers
can increase the number of simultaneous writers
Use Collections. newSetFromMap to construct concurrent set
ConcurrentSkipLists
Skip Lists are a probablistic alternative to balanced trees
something I invented back in 1988
ConcurrentSkipLists provide a concurrent sorted set implementation
and lots of other API improvements over TreeMaps
Java 6 only
CopyOnWriteArrayList
Using locking to ensure only one thread can update it at a time
any update copies the backing array
thus, read only operations don’t need any locks
iteration uses a snapshot of the array
allows concurrent modification and update
Suitable only if updates rare
Waiting for something to
happen
We briefly talked about join()
slides on web have been updated to discuss them
wait for another thread to terminate
There are lots of ways to have a thread wait until things are right for it to do something
wait/notify were the way to do this before Java 5
but now we have new ways that are often better: blocking queues and synchronizers
Blocking Queues and
Dequeues
A Queue is a first-in, first-out queue
A dequeue is a Double-Ended Queue
allows addition and removal at both ends
a dequeue can also serve as a stack
Queue notes
Blocking queues also offer timed offer and poll methods
Several different implementations, each with its own advantages
ConcurrentLinkedQueue
doesn’t support blocking, but allows for simultaneous addition/deletion
Array/Linked Blocking Dequeue/Queue
Synchronizers
Other ways to wait for some condition to be true
CountDownLatch
Semaphore
Semaphore
Contains a count of the number of permits available
You can acquire or release permits
no checking that you are releasing permits you have
really, just a counter
Acquire blocks if not enough permits are available
Fairness
Consider a Blocking queue where you atomically remove multiple elements
What happens if one person wants to atomically remove 10 elements from a queue that can contain up to 20 elements
but there is a constant stream of other threads that want to remove smaller number of elements? Starvation!
java.util.concurrent
.atomic
AtomicInteger
Encapsulates an integer
Sort of like a volatile int
but supports additional atomic operations:
int getAndIncrement()
int decrementAndGet()
boolean compareAndSet(int expect, int update)