• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

New question on K&B Chapter 9 Question 2

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


We want to guarantee that the output can be either XXYY or YYXX, but never XYXY or any other combination. Which of the following method definitions could be added to the Letters class to make this guarantee?(Choose all that apply.)

A. public void run() { write();}
B. public synchronized void run() {write();}
C. public static synchronized void run() {write();}
D. public void run() { synchronized(this){ write();}}
E. public void run() {synchronized (Letters.class) { write();} }
F. public void run() {synchronized (System.out) { write();} }
G. public void run() {synchronized (System.out.class) { write();} }

Answer is E and F.

Many threads explain why B and D aren't correct. Well understood. I also can see the points made about why E and F are correct.

My question is, what is all that stuff in the chapter about not synchronizing non-static fields from static methods and vice versa and why doesn't it apply here?
 
Karen Marie
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Statement from the book pg 711:

A static synchronized method and a non-static synchronized method will not blocck each other, ever. The static method locks on a Class instance while the non-static method locks on the this instace -- these actions do not interfere with each other at all.

Why is that not the case in the code above?
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The statement is basically talking about when you use the synchronized word as part of a method signature. In your example, a synchronized block is used, which has a little more flexibility.

In the example, the run() method must be overridden for Thread and therefore run() can not be static. However, synchronizing the run method won't solve our problem because it will only lock the single Thread instance - so nothing stops the second Thread instance from running!

So we need to put a lock on something more... unique. Enter the synchronized block! Using the block, we can put a lock on a static source even when we're in a non-static method. A block would also let us lock something non-static (like this) from our non-static method, but we already determined we needed something more unique.

So our block can put a lock on a static resource. The next time such a block is reached in code, it sees that the one single static resource is locked and this second block will simply have to wait until the first block is finished.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Karen]: My question is, what is all that stuff in the chapter about not synchronizing non-static fields from static methods and vice versa and why doesn't it apply here?

You mean, since name is not static, why don't we use non-static methods (or code blocks synchronized on this) in order to access that data? Well, some of the statements in the book may have become oversimplified. The section you're thinking of was talking about how to protect mutable (changeable) data. If name were chageable, then it would be appropriate to use non-static methods or blocks to protect it. However there's no way to achieve the other requirement of the problem (allow XXYY or YYXX but not XYXY etc) using nonstatic methods or code blocks synchronized on "this". So that would render the problem impossible.

But since the name field is not chanageable after instantiation, that's not a problem. Since name never changes, there's no need to protect access to it using synchronization. (Technically, name should be declared final in order to guarantee this - that's an error in the code. But it's outside the scope of the SCJP.) You don't need synchronization to protect access to name, but you do need it to enforce the XXYY-or-YYXX-but-not-XYXY requirement. The latter requires synchronization on a shared object, like Letters.class or System.out. It can't be accomplished with B or D.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Karen]:

Statement from the book pg 711:

A static synchronized method and a non-static synchronized method will not blocck each other, ever. The static method locks on a Class instance while the non-static method locks on the this instace -- these actions do not interfere with each other at all.

Why is that not the case in the code above?


It is true. I'm not sure why you think it isn't. It doesn't seem to be relevant though, because none of the code samples above put a static synchronized method up against a nonstatic synchronized method - those are two different options, never in the code at the same time (in this problem).
 
reply
    Bookmark Topic Watch Topic
  • New Topic