Why constructor body guarded by lock in SemaphoreOnLock implementations[JCIP 14.12]

Question

In Java Concurrency In Practice book auhor provides following implementation Semaphore on top of the ReentrantLock:

@ThreadSafe
public class SemaphoreOnLock {
    private final Lock lock = new ReentrantLock();
    // CONDITION PREDICATE: permitsAvailable (permits > 0)
    private final Condition permitsAvailable = lock.newCondition();
    @GuardedBy("lock") private int permits;

    SemaphoreOnLock(int initialPermits) {
        lock.lock();
        try {
            permits = initialPermits;
        } finally {
            lock.unlock();
        }
    }

    // BLOCKS-UNTIL: permitsAvailable
    public void acquire() throws InterruptedException {
        lock.lock();
        try {
            while (permits <= 0)
                permitsAvailable.await();
            --permits;
        } finally {
            lock.unlock();
        }
    }

    public void release() {
        lock.lock();
        try {
            ++permits;
            permitsAvailable.signal();
        } finally {
            lock.unlock();
        }
    }
}

Can you explain why do we use lock inside the constructor?

Is it related with visibility?

P.S.

At same book you can find also this class:

@ThreadSafe
public class SafePoint { 
    @GuardedBy("this") private int x, y;
    private SafePoint(int[] a) { this(a[0], a[1]); }
    public SafePoint(SafePoint p) { this(p.get()); }
    public SafePoint(int x, int y) { 
        this.x = x;
        this.y = y;
    }
    public synchronized int[] get() { return new int[] { x, y };
    }
    public synchronized void set(int x, int y) { this.x = x;
        this.y = y;
    }
}

author says that this class thread-safe.

this has an answer here --> http://stackoverflow.com/questions/12611366/constructor-synchronization-in-java — Ousmane D., Mar 13 '17 at 20:19
Possible duplicate of [Java Concurrency in Practice - Sample 14.12](http://stackoverflow.com/questions/10528572/java-concurrency-in-practice-sample-14-12) — Adonis, Mar 13 '17 at 21:48

score -1 · Answer 1 · answered Mar 13 '17 at 20:40

-1

the changes to int data type is not atomic which is why its guarded with locks

answered Mar 13 '17 at 20:40

Vinod Krishnan

141
2
13

Why do you think so? – gstackoverflow Mar 13 '17 at 20:51
please refer http://stackoverflow.com/questions/10528572/java-concurrency-in-practice-sample-14-12 – Vinod Krishnan Mar 13 '17 at 20:57
where did you see about atomicity in linke topic? – gstackoverflow Mar 13 '17 at 20:59
Its there, please check – Vinod Krishnan Mar 13 '17 at 21:16
There is nothing about this – gstackoverflow Mar 13 '17 at 21:32
"Non final fields are first initialized to default value and then the actual assignment will happen" either we should make it volatile or guard by lock – Vinod Krishnan Mar 13 '17 at 21:54
1

1. in your answer you wrote another, 2 In updated my topic I showed where author don't use synchronization in constructor – gstackoverflow Mar 14 '17 at 06:40

Why constructor body guarded by lock in SemaphoreOnLock implementations[JCIP 14.12]

P.S.

1 Answers1