• Post Reply Bookmark Topic Watch Topic
  • New Topic

Please help

 
Jagdish Kala
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please answer these interview questions.
1)How to synchronize a class variable?
2)If a class has two synchronized methods a(), b() and a thread t1 is accessing a(), can another thread t2 access b() simultaneously? why?
thanks in advance.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) is meaningless as worded.
2) is more or less the definition of "synchronized." Sounds like you need to pick up a Java book and do some reading about threads.
 
ratnadeep rakshit
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi jagdish kala,
well the answer to ur question is ---
1) You cannot synchronize on a variable...only Objects or its methods can be synchronized.
2) If both the synchronized methods a() and b() are of the same object, then at a time only one thread can access those two synchronized methods.Other methods are available for use however.
This is how the java shynchronization works...no answer to ur why!!!
Now a last word...there are som people in this planet who feels gr8 just pulling othes legs...they forget however tat they had already stepped inside the quicksand of pride...
have fun and never stop asking questions...
 
john kerry
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with ratnadeep here.
But there is definitely an answer to why?
The key is that during synchronization your object gets locked.
Therefore, you cannot enter the other synchronized method b()
Hope it helps
 
Jagdish Kala
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Ernest, ratnadeep and john for your valuable inputs. I am happy that even John Kerry is answering my questions!
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Erm, synchronising a class variable...what about the volatile modifier?
--Tim
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I guess a2 may run method b() before a1 finished a().
It's not told to be the same object, for which a() or b() is called.
[ April 23, 2004: Message edited by: Stefan Wagner ]
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Erm, synchronising a class variable...what about the volatile modifier?

I think we cannot synchronize variables, but threads on locks. It happens that we can use any object as a lock and thus a static reference variable qualifies.
Also volatile has nothing to do with preventing simultaneous execution of a portion of code --synchronizing-- What volatile buys you is the visibility of the changes made by a thread to the content of the variable respect others threads.
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jose...you're right.
I read "synchronising a variable" as "protecting a variable from problems caused by having multiple threads access it". I thought volatile did that, but upon reading the JLS more thoroughly I see that it provides only very weak guarantees...probably too little for most practical purposes. Ironically the link I provided above proved me incorrect
Having read more, I can't see how 'volatile' is useful at all. This part of the JLS makes it sound like it prevents certain compiler optimisations, but the behaviour of your Java code shouldn't be dependant on how it's optimised by the compiler, right?! That said, I didn't read all of chapter 17...it's a little *ahem* dry.
Anyway, this is completely OT, but there ya go.
Cheers,

--Tim
 
Eddie Vanda
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My take on volatile is that it combines sub operations on large values such as long so that other threads cannot see a partial update of the variable. I ran some code to see if I could see this happen without the volatile qualifyer and it did not. I guess that the Pentium has hardware indivible instructions for handling longs so volatile is not needed for longs on a Pentium or equivalent. Reminds me of assembly code on the 8088 from the old days when you used to stop interrupts for a few instructions while updating large primitive values.
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dough Lea wrote in Concurrent Programming in Java:

Using volatile fields can make sense when it is somehow known that only one thread can change a field, but many other threads are allowed to read it at any time.

I use it quite often to qualify the boolean variable that stops the execution of a thread. In fact Dough warns against using such variable without volatile.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!