CodeGym/Help with Java Tasks/What does a Class-level lock mean?

Level 23

Szekesfehervar

14.05.2021
692views
11comments

What does a Class-level lock mean?

Question about the task

Resolved

1) What is the point of class-level lock of the Iron class? This class does not contain any methods. Then what does it lock in fact?? 2) Why is the (Person.class) lock not correct solution? The output appeared in the correct order (as if there were only 1 piece of iron). 3) When I wrote this: synchronized(Clothes.class), the output appeared in the correct order. When I wrote this: synchronized (Solution.class), the output still appeared in the correct order. So that means perhaps is it irrelevant what I write into the parentheses?? ... But the same question just in other words: what is the meaning of "synchronized" with lock of one class, and what is the meaning of "synchronized" with lock of another class? What is the difference?

Back to the daily grind...
Add one synchronized keyword to make diana and steve take turns ironing, since there's only one iron!

Hint:
Use class-level locking.

Requirements:

The Solution class must contain the public static Clothes class.
The Solution class must contain the public static Iron class.
The Solution class must contain the public static Person class.
The Person class must be a thread.
The Person class's run() method must have a synchronized block.
The synchronized block must use a class-level lock.

package com.codegym.task.task17.task1718; /* Ironing */ public class Solution { public static void main(String[] args) { Person diana = new Person("Diana"); Person steve = new Person("Steve"); diana.start(); steve.start(); } public static class Person extends Thread { public Person(String name) { super(name); } @Override public void run() { synchronized (Person.class) { Iron iron = takeIron(); Clothes clothes = takeClothes(); iron(iron, clothes); returnIron(); } } protected Iron takeIron() { System.out.println("Taking the iron"); return new Iron(); } protected Iron returnIron() { System.out.println("Returning the iron"); return new Iron(); } protected Clothes takeClothes() { return new Clothes("T-shirt"); } protected void iron(Iron iron, Clothes clothes) { System.out.println(getName() + " is ironing a " + clothes.name); } } public static class Iron { } public static class Clothes { String name; public Clothes(String name) { this.name = name; } } }

Comments (11)

Popular
New
Old

You must be signed in to leave a comment

Thomas

Level 41 , Bayreuth, Germany

14 May 2021, 21:04

useful

object level locking: that's possible only for instance methods. With that you allow only one thread to enter the synchronized code block of a certain instance. If you have two instances of a class, then it is possible that two different threads run at the same time the same time the same synchronized method but on that two diffenent objects of a class. But it is not possible that two threads run a synchronized code block in the same instance. class level locking: with that you can synchronize static methods as well and I think it is mostly used for that. But you also can lock instance methods on class level, too. Then just one thread is allowd in the synchronized block for all instances of that class.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

15 May 2021, 14:42

I think in part this is the key to my questions: "You also can lock instance methods on class level, too. Then just one thread is allowed in the synchronized block for all instances of that class." But it involves more questions for me. According to this rule I wrote an example, and the questions are in its comments. Please check them: do i understand this rule correctly?

public void run() {
    synchronized (Iron.class) {
        System.out.println("abcdefghijk"); // This command has nothing to do with any instance of Iron.class, so multiple threads can work on it at the same time.
        Clothes clo = new Clothes("jeans"); // This command has nothing to do with any instance of Iron.class, so multiple threads can work on it at the same time.
        Person tom = new Person("Tom"); // This command has nothing to do with any instance of Iron.class, so multiple threads can work on it at the same time.
        Solution sol = new Solution();   // This command has nothing to do with any instance of Iron.class, so multiple threads can work on it at the same time.

        Iron iron = takeIron(); // This command works with one instance of Iron.class, so it can only be executed by one thread at a time, and the others have to wait exactly here.
        Clothes clothes = takeClothes();
        iron(iron, clothes);
        returnIron();
    }
}

Thomas

Level 41 , Bayreuth, Germany

15 May 2021, 16:30

I do not know exact details about the implementation so I can't help you much there. My understanding of it is, that if a thread enters the class level synchronized block, then it gets that lock. From that point on it is the only thread that can work on Iron class methods and fields inside that block. From that point on there are two possible ways to implement that (maybe more but these are obvious for me ;) ). a) what you described above, the thread not holding the lock can go till the first use of an Iron method/ field and then gets blocked and now has to wait for the lock. b) one thread holds the lock and the rest has to wait till the can get the lock and enter the synchronized block (but I doubt that's how it is implemented) good qustion, made my head spin

Gellert Varga

Level 23 , Szekesfehervar, Hungary

15 May 2021, 16:51

OK thanks! In this case I will ask Guadalupe, and probable we will get to know the answer:)

Guadalupe Gagnon

Level 37 , Tampa, United States

15 May 2021, 17:32

useful

Class level locks will lock all synchronized blocks that are locked with class level block. This means static synchronized methods as well as all synch(class) blocks. Only one thread at a time can enter these while all other threads have to wait at the start:

void someMethod() {
   // synch block 1, has a class level lock
   synchronized (Iron.class) { // waiting threads stop here
   /* some lines of code  */
   }

   // synch block 2, has a class level lock
   synchronized (Iron.class) { // threads wait here
      /* some lines of code  */
   }

   // synch block 3, has an object level lock
   synchronized (this) { // threads wait here
      /* some lines of code  */
   }
}

// synch block 4, has a class level lock
static synchronized someOtherMethod() { // threads wait here
   /* some lines of code */
}

Here, if a thread is in the synch block 1, then ALL synch blocks that hold a class level lock (1, 2, and 4 in this code) will be locked simultaneously. Any other thread trying to access any one will have to wait on the synchronized line until the thread that holds the lock leaves the synch block. It works the same if any thread enters synch blocks 1, 2, and 4; the other two will also lock and not allow threads in. I added an object level block in this code too, synch block 3, this one will not lock with when a thread enters one of the other synch blocks that hold a class level lock. If there were more object level blocks in this code (non-static methods and sync(this) blocks), then when one thread enters one of them, it will lock all the other ones for that object only. So if you had two objects and a thread entered an object level block in object1, then all the object level locks in object1 would lock but none of the object level blocks in object2 would lock.

Guadalupe Gagnon

Level 37 , Tampa, United States

15 May 2021, 17:35

useful

Your notes seem to imply that multiple threads can enter a synch block but only wait on a shared resource. This is not true. The wait point would be at the very start of the synch block. Only one thread at a time can execute code in a synch block as well as any other synch block that shares the same lock.

Guadalupe Gagnon

Level 37 , Tampa, United States

15 May 2021, 18:07

useful

Here is an interesting situation that can occur: When using a variable as a lock, it is locked with the object associated with that variable and not the variable itself. So if a new objected is created with that variable then the effective lock will change. Say a thread enters a synch block on some variable and while it is still in the block the variable gets a new object. That thread in the synch block will hold the lock on the old object but since its effectively a new lock now another thread can enter. Take this code for example:

public class Solution {
    String lock = "green";

    public static void main(String[] args) throws Exception {
        Solution sol = new Solution();
        Runnable x = () -> {
            try {
                sol.myMethod();
            } catch(Exception ignored) {}
        };

        new Thread(x, "Thread 1").start();
        Thread.sleep(1000);
        new Thread(x, "Thread 2").start();

    }

    void myMethod() throws Exception{
        System.out.println(Thread.currentThread().getName() + " entered my method");
        synchronized (lock){
            System.out.println(Thread.currentThread().getName() + " enters synch block");

            if(lock.equals("green")){
                System.out.println("\t and changes the value of 'lock'");
                lock = "red";
            }

            System.out.println(Thread.currentThread().getName() + " enters infinite loop");
            while(true); // infinite loop
        }

    }
}

Here 2 threads access one method that is locked with a String. Because Strings are immutable, when the value changes it creates a whole new String. This means that both Threads in this code can access the synch block because the lock changes.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

15 May 2021, 19:59

Your words and examples are very clear, i think i understood all these well.:) Thank You! But one thing isn't clear enough yet. As I wrote in point 3 of my original shared question: When I wrote this in task-1718: synchronized(Clothes.class), the output appeared in the correct order. When I wrote this: synchronized (Solution.class), the output still appeared in the correct order. When I wrote this: synchronized (Person.class), the output still appeared in the correct order, but the task failed to pass testing, and the validation said: "Be sure that the synchronized block locks the Iron object." ((I think it wanted to say: the Iron class.)) So if we look at this problem from the viewpoint of getting the right output, then we can say it is irrelevant what I write into the parentheses after the synch keyword?? Is there at all any significance of which class is written there in the parentheses? (As you showed, we can even write a string, too.)

Guadalupe Gagnon

Level 37 , Tampa, United States

15 May 2021, 20:46

solution

Getting the correct output in this task only requires that the lock be something that is a shared resource among multiple objects and can not change like the String example I used 2 posts above. You could technically use a final static object in the Solution class, but the task requirements say that you should use a class level lock. It is strange that they require the Iron.class for the lock and not any other class, as the results would all be the same. The only reason to use one class and not the other would be if there were static synchronized methods in one or more of the classes that should not be locked with this block of code, as a class level lock would lock those methods as well, but that scenario does not exist in this code.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

15 May 2021, 21:14

Thank You Guadalupe very much!! You made all of my questions completely clear now.:)

Thomas

Level 41 , Bayreuth, Germany

16 May 2021, 05:51

Good that you asked Guadalupe ;) Even though I knew that all I let CG confuse me with only accepting Iron.class and thought about problems that do not exist. That was a very good in depth reading now.