Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

threads problem

 
geeta vemula
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I got it from K & B.

public class Logger {
private StringBuilder contents = new StringBuilder();
public void log(String message) {
contents.append(System.currentTimeMillis());
contents.append(": ");
contents.append(Thread.currentThread().getName());
contents.append(message);
contents.append("\n");
}
public String getContents() { return contents.toString(); }
}
How can we ensure that instances of this class can be safely used by multiple threads?
A. This class is already thread-safe.
B. Replacing StringBuilder with StringBuffer will make this class thread-safe.
C. Synchronize the log() method only.
D. Synchronize the getContents() method only.
E. Synchronize both log() and getContents().
F. This class cannot be made thread-safe.
Answer:
� 3 E is correct. Synchronizing the public methods is sufficient to make this safe, so F is false.

But I think If we use StringBuffer then also it may solve the problem as its methods are synchronized. That means, append method is synchronized , so it will acquire the lock on contents, so no two threads can access that object.

Kindly clear me where i went wrong?

Thanks,
Geeta Vemula
 
Henry Wong
author
Marshal
Pie
Posts: 20889
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But I think If we use StringBuffer then also it may solve the problem as its methods are synchronized. That means, append method is synchronized , so it will acquire the lock on contents, so no two threads can access that object.

Kindly clear me where i went wrong?



Well, assuming choice B is correct.... Let's say that two threads simultaneously calls the log() method. Will the logs be ...

Time: Name Message
Time: Name Message

Or can it be something like this?

Time: TimeName : Message
Message

Henry
 
geeta vemula
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it is still not clear to me. here the method append is synchronized, then it acquires which object's lock? if it acquires the lock of contents then how other thread is able to access or modify contents?


Thanks,
Geeta Vemula.
 
Punit Singh
Ranch Hand
Posts: 952
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You want to say if this would have been... then what was happend?


Suppose you have 2 threads simultaneously calling log:
thread1 entered log() and performed
contents.append(System.currentTimeMillis());
Now as thread1 performing append() and it is synchrnized method,
so thread2 cannot enter in append() method. Fine .....

Now content="1229666912979" //currentTimeMillis

Now after completing first append() suppose thread1 goes to sleep.

Here comes thread2, it sees no lock on StringBuffer object.
It will take lock and again call
contents.append(System.currentTimeMillis());
then what will happen to content?

content="12296669129791229666912979".//is it what you want?

You got idea or any doubt?
 
Harikrishna Gorrepati
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Punit, You demonstrated this very well. Quick question, When should we go for StringBuffer then? Even though it is synchronized, we are not able to leverage it here. Could you please show us some sample code ? Also, If we synchronize on any method in a class, we will get lock on whole object know ?? Why should we synchronize 2 methods ?
 
Punit Singh
Ranch Hand
Posts: 952
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Harikrishna Gorrepati wrote:If we synchronize on any method in a class, we will get lock on whole object know ?? Why should we synchronize 2 methods ?




Run above example and do some research on output as read() method is not synchronized, two threads can enter this method simultaneously.
Now modify read method with this method and run again.


you can see in first example you do not have lock on read() method, so no lock on your SharedObject, threads are entering in read method without taking any permission, while for entering update method then are taking permission from SharedObject. And SharedObject is giving permission when a thread is exiting from the update method. you can verify this from the println() in the output.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic