aspose file tools*
The moose likes Mock Exam Errata and the fly likes Thread question from Marcus' exam#2 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Mock Exam Errata
Bookmark "Thread question from Marcus Watch "Thread question from Marcus New topic
Author

Thread question from Marcus' exam#2

raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Here is the question #42:
Which of the following statements about threading are true
1) You can only obtain a mutually exclusive lock on methods in a class that extends Thread or implements runnable
2) You can obtain a mutually exclusive lock on any object
3) A thread can obtain a mutually exclusive lock on a synchronized method of an object
4) Thread scheduling algorithms are platform dependent
correct answers are marked 2,3,4
I'm in doubt about answer No 3
Locks are usually obtained on an instance or class (if method
is static syncronized) not on method
Can anyone clear this to me ?
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
Hi Raimondas,
You can create a synchronized method.

The field 'counter' could only be changed by one thread at a time.
Hope that helps.

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform


Jane Griscti
SCJP, Co-author Mike Meyers' Java 2 Certification Passport
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Hi Jane,
That's clear, what I'm pointing to is that threads
can not obtain lock on a method as stated in answer #3.
JLS (Java Language specification) and other sources I've
looked into say that every object has its own lock (kind of
hidden object) but this is an instance lock, not method lock.
You can NOT lock a single method in the object (do you ?).
What you lock is an instance of the class so no other thread
can access this object VIA synchronized method, if another
thread is executing same method at that time.
Do I miss something or I interpret answer #3 incorrectly ?
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Can someone answer this? I answered the same way raimondas did and for the same reason.
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
Hi Eric, Raimondas ...
Apologies for not responding earlier; missed the thread.
The Java Programming Language: 2nd Edition by Ken Arnold and James Gosling states:

If one thread invokes a <code>synchronized</code> method on an object, that object is locked. Another thread invoking a <code>synchronized</code> method on the same object will block until the lock is released.


The lock is on the object or instance but the method is part of that object; by accessing the object's synchronized method the thread obtains a lock on the object via the object's method.
If another thread invokes a synchronized method to access the same object; it will block until the method invoked by the first thread finishes executing.
For example, if threadA invokes the synchronized method mX on objX and a second thread, threadB, attempts to invoke method mX on objX; the second thread will block until method mX invoked by threadA finishes executing and the lock is released.
Does that help?

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Thanks for the answers,
But unfortunately both answers missed the point:
I state that this formulation is incorrect, by invoking synchronized method of the object thread has to obtain mutually exclusive lock ON THIS OBJECT not the method. You could formulate it like this: thread has to obtain lock via/by means of the syncronized method or similar but not "A thread can obtain a mutually exclusive lock on a synchronized method of an object" which would mean that if there are two synchronized methods in the object each of them could be executed by different threads.
What you say is absolutely correct but read my initial post - it is not about what synchronized means, that's perfectly clear, I was in doubt HOW one of the answers is formulated. I do think it is incorrect. Just to insure myself I decided to post it here since group is caller ERRATA.
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
Hi Raimondas

"A thread can obtain a mutually exclusive lock on a synchronized
method of an object" which would mean that if there are two synchronized methods in the object each of them could be executed by different threads.

Locks are per thread. If Thread_a calls synchronized method_a in Object, it obtains a lock on the Object. If Thread_b then calls synchronized method_b for the same Object, Thread_b will be blocked until Thread_a releases the lock.
From the Java Programming Language by Ken Arnold and James Gosling, p183

If one thread invokes a synchronized method on an object, that object is locked. Another thread invoking a synchronized method on that same object will block until the lock is released.
Synchronization forces execution of the two threads to be mutally exclusive in time.

Hope that is clearer.
------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
[This message has been edited by Jane Griscti (edited April 01, 2001).]
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Hi Jane,
It seems we have discussion out of almost nothing
What we try to match here in fact is terminology, so JLS says:



The synchronized statement (�14.18) computes a reference to an object; it then attempts to perform a lock action on that object and does not proceed further until the lock action has successfully completed....

A synchronized method acquires a lock (�17.1) before it executes. For a class (static) method, the lock associated with the Class object for the method's class is used. For an instance method, the lock associated with this (the object for which the method was invoked) is Used....

Let us again consider the thread that calls hither. According to the rules, this thread must perform a lock action (on the instance of class SynchSample on
which the hither method is being called) before the body of method hither is executed....
The last one is an example from JLS. All this stuff above assumes that it is would be incorrect to say "lock on a synchronized method of an object" since locks are associated with objects, not methods, while sync. methods or blocks being entry point into the object, by passing which a permission (lock) is required.
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
Hi Raimondes,
LOL ... Yes, it does seem we've been talking at cross purposes
I guess it's just a combination of the wording and the way we think of objects. To me, the method is part of the object ie it belongs to the object; so Marcus saying "A thread can obtain a mutually exclusive lock on a synchronized method of an object" makes sense; if you have a lock on the object you also have a lock on the synchronized methods for that object because the methods are part and parcel of the object.
But, that's just the way I think about objects; and it could be the wrong way
Could be this whole discussion would never have occurred if Marcus had said: "A thread can obtain a mutually exclusive lock by invoking the synchronized method of an object"
Marcus ... if you're reading any of this ... any particular reason you worded the question as you did?

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
Marcus Green
arch rival
Rancher

Joined: Sep 14, 1999
Posts: 2813
Been reading this discussion, actually printed it out once. Choice of words was probably based on my ignorance. Have learnt a lot more about Threading recently. That question has gone through several word changes as my understanding has become greater.
Marcus


SCWCD: Online Course, 50,000+ words and 200+ questions
http://www.examulator.com/moodle/course/view.php?id=5&topic=all
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Hi Marcus,
Thanks for your reply.
Your mocks are good. Questions well formed. I left them for the very last days of preparation.
Keep going that way !
Jane Griscti
Ranch Hand

Joined: Aug 30, 2000
Posts: 3141
Hi Marcus,
Out of curiosity, 'cause I'm still weak on threads, am I right in thinking of the methods as part and parcel of the object?
If a thread has a lock on an object then all other synchronized methods for that object will block until the first thread releases the lock ie a second thread calling a different synchronized method on the same object will have to wait for the lock?
Thanks,
Jane
raimondas zemaitis
Ranch Hand

Joined: Feb 23, 2001
Posts: 104
Hi Jane,
Heres quite long excerpt from the book "Tricks of the Java programming gurus", chapter "Concurrency and Synchronization"
The concept of a monitor was introduced by C.A.R. Hoare in a 1974 paper published in the Communications of the ACM. Hoare described a special-purpose object, called a monitor, which applies the principle of mutual exclusion to groups of procedures (mutual exclusion is a fancy way of saying "one thread at a time"). In Hoare's model, each group of procedures requiring mutual exclusion is placed under the control of a monitor. At runtime, the monitor allows only one thread at a time to execute a procedure controlled by the monitor. If another thread tries to call a procedure controlled by the monitor, that thread is suspended until the first thread completes its call.


...When a Java synchronized method is invoked, a complicated process begins. First, the virtual machine locates the monitor associated with the object on which the method is being invoked (for example, if you are calling obj.method(), the VM finds obj's monitor). Every Java object can have an associated
monitor, although for performance reasons, the 1.0 VM creates and caches monitors only when necessary. Once the monitor is located, the VM attempts to assign ownership of the monitor to the thread invoking the synchronized method. If the monitor is unowned, ownership is assigned to the calling thread, which is then allowed to proceed with the method call. However, if the monitor is already owned by another thread, the monitor cannot be assigned to the calling thread. The calling thread will be put on hold until the monitor becomes available. When assignment of the monitor becomes possible, the calling thread is assigned ownership and will then proceed with the method call.


Hope this helps.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread question from Marcus' exam#2