Concurency Flashcards

0
Q

Can atomicBoolean be used in place of a Boolean?

A

No it does not extend Boolean

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
1
Q

Features of volatile

A

The value seen by a thread is always reread from main memory before use.
Any value written by a thread is always flushed through to main memory before the instruction completes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

AtomicInteger isn’t an Integer but it does extend Number…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Lock interface in java.util .concurrent.locks. This ships with a couple of implementations…

A

ReentrantLock—This is essentially the equivalent of the familiar lock used in Java synchronized blocks, but it’s slightly more flexible.
ReentrantReadWriteLock—This can provide better performance in cases where there are many readers but few writers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

The Lock interface can be used to completely replicate any functionality that is offered by block-structured concurrency…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

The CountDownLatch is a simple synchronization pattern that allows for multiple threads to all agree on a minimum amount of preparation that must be done before any thread can pass a synchronization barrier…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Synchronization is required for reliable communication between threads as well as for mutual exclusion

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

TimeUnit.SECONDS.sleep(1)is valid sleep functionality

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

This optimization is known as hoisting, and it is precisely what the HotSpot server VM does…

A

In the absence of synchronization, it’s quite acceptable for the virtual machine to transform this code: while (!done) i++;
into this code:
if (!done) while (true) i++;

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

synchronization has no effect unless both read and write operations are synchronized over a common used variable

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

While the volatile modifier performs no mutual exclusion, it guarantees that any thread that reads the field will see the most recently written value…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

If you need only inter-thread communication, and not mutual exclusion, the volatile modifier is an acceptable form of synchronization, but it can be tricky to use correctly…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

If you need only inter-thread communication, and not mutual exclusion, the volatile modifier is an acceptable form of synchronization, but it can be tricky to use correctly…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

As a rule, you should do as little work as possible inside synchronized regions…

A

Yes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

How many kinds of tasks are…

A

There are two kinds of tasks: Runnable and its close cousin, Callable (which is like Runnable, except that it returns a value). The general mechanism for executing tasks is the executor service

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

The higher-level utilities in java.util.concurrent fall into three categories…

A

the Executor Framework, concurrent collections; and synchronizers.

16
Q

Unless you have a compelling reason to do otherwise, use ConcurrentHashMap in preference to Collections.synchronizedMap or Hashtable

17
Q

Under most circumstances, normal initialization is preferable to lazy initialization

18
Q

If you use lazy initialization to break an initialization circularity, use a synchronized accessor, as it is the simplest, clearest alternative: // Lazy initialization of instance field - synchronized accessor private FieldType field;
synchronized FieldType getField() {
if (field == null) field = computeFieldValue(); return field}

19
Q
If you need to use lazy initialization for performance on a static field, use thelazy initialization holder class idiom. This idiom (also known as the initializeon-demand holder class idiom) exploits the guarantee that a class will not be initialized until it is used [JLS, 12.4.1]. Here’s how it looks:
 // Lazy initialization holder class idiom for static fields private static class FieldHolder { 
static final FieldType field = computeFieldValue(); 
} 
static FieldType getField() { return FieldHolder.field; }
20
Q
If you need to use lazy initialization for performance on an instance field, use the double-check idiom
Double-check idiom for lazy initialization of instance fields 
private volatile FieldType field; 
FieldType getField() { 
FieldType result = field; 
if (result == null) {
// First check (no locking) 
synchronized(this) { result = field; if (result == null)
// Second check (with locking) field = result = computeFieldValue(); } } return result
21
Q

Prior to release 1.5, the double-check idiom did not work reliably because the semantics of the volatile modifier were not strong enough to support it…

22
Q

Threads should not run if they aren’t doing useful work…

A

Yes thus while true is not effective

23
Q

Threads should not busy-wait, repeatedly checking a shared object waiting for something to happen…

24
Q

Thread priorities are among the least portable features of the Java platform…

25
Q

thread groups are obsolete…