Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Threads again

 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Question 11 of dan chisholm's mock exam: Threads n�2:

Answer : output ABC
Explanations:


Inside the main method a new thread, t1, is started and will move into the running state at the discretion of the thread scheduler. The A.run method invokes the wait method on the String array object, sa, causing the thread to block until another thread invokes the sa.notify method. Before the B.main method invokes sa.notify all of the elements of the String array object, sa, have already been updated.


BUt as the block

is synchronized, there's no importance if sa.notify() is called before or after updating sa's array. Anyway, we go out of the synchronized block when all the instructions inside it have been executed
So, the following code should give exactly the same result, no?

I tested it, and on my computer, it's the case. But can we generalize?
Thanks for your answer,
Cyril
 
Ranch Hand
Posts: 443
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think when a thread issued a notify()/notifyall() call, what it is saying to other threads in the wait set is, "Hey, I am about to release the lock on this object. Get ready!". However, this does not mean that that thread will give up the lock immediately, nor will it guarantee a certain thread to obtain the lock.
Just my 2 cents
 
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cyril, the notify() method MUST be there in order to make sure that your code will not run forever. Imagine what would happen if t1 gets executed before the main thread gets the lock on sa, i.e before the code below is execuuted:
synchronized (sa) {
sa[0] = "Done";
sa[1] = "A";
sa[2] = "B";
sa[3] = "C";
sa.notify();
}
It would check that: "!sa[0].equals("Done"))", whcich is true, so it goes and it waits! releases the lock on sa (because of wait) and then main can go further with the code above (setting the values of sa). Now if there is NO notify in the end, thread t1 will wait forever, so your program will never end!
Try to put a Thread.yield() or Thread.sleep(10) after you start t1 (so after the t1.start(); call), to give a chance to t1 to start its execution before the main. You will see that without a notify, your program runs forever.
Miki
 
cyril vidal
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Miki,
Thanks for your response.
As you say, i'm sure that notify() instruction is necessary so that t1 thread doesn't have to wait for ever.
But my question was more precisely: is the place of this notify() methodin synchronized code necessary at the end?
Normally, it should'nt harm, because the lock is out when all the block has been executed.
But is it really the case?
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both the code exactly the same as notify call has nothing to do with releasing of the lock.
Inorder to make sure that code doesn't wait for ever i think it better to use join rather than the wait & notify in the above scenario.
Thomas
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cyril, you are correct that the notify method can be placed anywhere within the synchronized block.
In very formal terminology,
Notification actions occur upon invocation of methods Object.notify() and Object.notifyAll(). Let thread T be the thread executing either of these methods on Object M, and let N be the number of lock actions by T on M that have not been matched by unlock actions.
If N is greater than zero and this is a notify operation, then, if M's wait set is not empty, a thread U that is a member of M's current wait set is selected and removed from the wait set. (There is no guarantee about which thread in the wait set is selected.) This removal from the wait set enables U's resumption in a wait action. Notice however, that U's lock actions upon resumption cannot succeed until some time after T fully releases the lock for M.
From Proposed revision to Section 17.4, Wait Sets and notification , Doug Lea
Relevant to your question is the last sentence.
 
cyril vidal
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The answer to the question ... in the mock exam from the same person, N�3, question 9

If an Object.notify method call appears in a synchronized block, then it must be the last method call in the block.


Response: False.
Explanation:


Suppose that thread T1 is holding the monitor for an object, A, within a synchronized block. If thread T1 calls the notify method immediately after entering the synchronized block, then no other thread can grab the monitor for object A until T1 leaves the synchronized block. For that reason, the transfer of control from thread T1 to any waiting thread can not be accelerated by moving the notify method to an earlier point in the synchronized block


So notify()'s position in synchronized block doesn't matter..
 
This guy is skipping without a rope. At least, that's what this tiny ad said:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic