• Post Reply Bookmark Topic Watch Topic
  • New Topic

Barrier implementation: endlessly wait for what?  RSS feed

 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is a simple class implementing barrier:

I know the concept of a barrier, but don�t thoroughly understand the logic in the code above. What if I remove the "break;" in the while loop? There will be an endless waiting. What does it endlessly wait for? In another word, why is there a "break;"? Anyone could explain to me please? Thank you very much in advance.

Regards,
Ellen
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It looks to me that the while(true) loop is just being used to allow for an InterruptedException being thrown from wait(). If the wait() completes due to the lock being regained, you can continue past the barrier, otherwise you wait some more.
If you remove the break, you will stay in that sync method forever.
So on entering sync(), you have the lock. If you see the number of waiters exceeds the barrier limit, then you wake up the other waiters and continue. If you see that not enough waiters are waiting you enter the loop until you are woken via the lock being regained, and then return from sync(). If you are woken via an Interrupted exception it was not because some other thread saw that there were enough waiters so you must wait on.
Sort of...
-Barry
[ January 13, 2003: Message edited by: Barry Gaunt ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Barry,
Thanks for your reply. Now I understand the break. But another question: what does the wait() wait for and actually who notifies it? Assume I am expecting 5 threads for the barrier, now there are 4 threads arrived, does the very 5th arriving thread notify the waiter( who is the waiter? The OS? Daemon thread? JVM? ) and then the while loop breaks? I am not clear about this scenario, any explaination please? Thank you very much!

Regards,
Ellen
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ellen, phew! I'll try.
The wait() is waiting to get the lock on the Barrier instance (object). It's the same one obtained on entering the synchronized sync() method, and released when wait() was invoked. Going into wait and releasing the lock is atomic, by the way.
The wait() is nomally left when another thread does the notifyAll(). All threads waiting will wake, and break out of that loop. If the notify() method had neen used, instead of notifyAll() one thread only would be notified, but you cannot say which (unless there is only one, of course).
That's really all I can tell you from the programmer's standpoint.
As for the implementation details I guess you will have to wait for a Guru, or you can try the JLS, or JVM specification. You can, however, expect that the actual implementation is highly dependent upon the OS's implementation of thread scheduling, if it has it.
Gets real messy...
-Barry
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ellen, hi again
The barrier reminds me a bit of those faux-Japanese garden water ornaments where water trickles into a half-open bamboo pipe; as soon as the amount of water in the pipe reaches a certain threshold, the weight will cause the pipe to tilt, dump all of its water into the pond, and then move back to its original position because the water's gone now... in the same way, the Barrier can receive threads in a steady trickle and release all of them at once as soon as it's "full".
As far as the internal implementation of synchronization, waiting and notification goes, if you really want to know the gory details you can read section 17.14, Wait Sets and Notification, of the Java language specification.
By the way, looking at the code provided, I don't like the way the code catches Exception; better catch InterruptedException 'cause that's the only thing thrown there really and it makes the code so much less obscure.
- Peter
[ January 14, 2003: Message edited by: Peter den Haan ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And I was right, following that link was like a glimse of programmers' hell
-Barry
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Dr. den Haan,
Thank you very much for the link. Guess what, "The Java Language Specification" is just one of the three literatures( the other two are: Concurrent Programming in Java-Design Principles and Patterns and The Java Virtual Machine Specification) specified by my professor for the concurrency course, and his research area is:
Formal specification of communication protocols
Application and development of formal description techniques
Generic communication systems
Real time aspects of communications systems
FDT-based efficient implementation
Look at the title of the board you are moderating
The Java Language Specification was borrowed by someone else from the liberary, I only got the chance to have a look at the other two--then I understood why they were not borrowed away by other students--Obviously they are for you masters but not for us pupils I had a look at the link you offered, much more accessible than the JVM specification. I�m printing it off. Thank you soooooooo much for the instruction!
We will run into Sockets and Internet Protocols in 2 or 3 weeks, I am turning around to your board.
Best Regards,
Ellen
[ January 14, 2003: Message edited by: Ellen Fu ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!