Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Questions about timing within synchronized blocks

Reply
Thread Tools

Questions about timing within synchronized blocks

 
 
Robert Mark Bram
Guest
Posts: n/a
 
      05-31-2004
Hi All!

I have some questions about timing with synchronization.. Which is better:

Object sync;
....
synchronized (sync){
// Do important stuff..
sync.notifyAll();
} // end synchronized

or this:
synchronized (sync){
// Do important stuff..
} // end synchronized
sync.notifyAll();

In the first example, is there any chance that the timing will stuff up and
when blocked threads get notified, Java still thinks control is in the
synchronized section?

If I do something like this:
synchronized (sync){
// Do important stuff..
sync.notifyAll();
// Do more important stuff..
} // end synchronized

Obviously this is deadlock making code.. but what if "Do more important
stuff" was just "i+=1".. could it still work then?

Thanks for any advice!

Rob



 
Reply With Quote
 
 
 
 
Carl Howells
Guest
Posts: n/a
 
      05-31-2004
Robert Mark Bram wrote:
> Hi All!
>
> I have some questions about timing with synchronization.. Which is better:
>
> Object sync;
> ...
> synchronized (sync){
> // Do important stuff..
> sync.notifyAll();
> } // end synchronized
>
> or this:
> synchronized (sync){
> // Do important stuff..
> } // end synchronized
> sync.notifyAll();
>


The second case will throw an IllegalMonitorStateException. (I think
that's the name of the exception, anyway.) Calls to wait and
notify[all] must be inside blocks synchronized on the object they're
being called on.

> In the first example, is there any chance that the timing will stuff up and
> when blocked threads get notified, Java still thinks control is in the
> synchronized section?


No. But see below. You are *very* confused.

> If I do something like this:
> synchronized (sync){
> // Do important stuff..
> sync.notifyAll();
> // Do more important stuff..
> } // end synchronized
>
> Obviously this is deadlock making code.. but what if "Do more important
> stuff" was just "i+=1".. could it still work then?


That code has no more chance of causing a deadlock than if all the
important stuff was before the notifyAll call.

You completely don't understand the semantics of wait and notify.
(notifyAll is just a special case of notify, so I won't bother
mentioning it explicitly further.)

When you call wait on an object, you first must have that object's lock.
(In other words, be in code that has synchronized on that object.)
When wait is called, it does two things (initially). First, it
*releases* the lock on the object it was called on. Second, it puts the
current thread into a non-runnable (system dependent for the details,
but whatever) state, and then execution moves to some other thread.

When you call notify on an object, you first must have that object's
lock. (Same as with wait). When notify is called, it does one thing
directly, which is to put some thread (if any exist anyway) that is
waiting on that object back into the runnable state. But notify doesn't
cause the lock to be released in the current thread, nor does it cause
the waiting thread to gain the lock. (This is the only spot notifyAll
differs from notify, in that notifyAll performs that action for *all*
waiting threads. But the difference is very minor, and typically notify
does what you want anyway.)

Then, the code that called notify continues executing. Any threads that
were waiting attempt to regain the lock on the object they waited on.
The wait() method won't actually return until that lock is re-acquired.
So, the wait() call won't ever return for more than one thread
simultaneously, and it won't ever return until the code that notified it
leaves the synchronized block in which it acquired the lock for that
object. (Or if it was a version of wait that had a timeout, and timed
out, wait won't return until it reacquires the lock on the object, which
may or may not be immediate, depending on whether there is contention
for the lock.)

In summary... Your first and third code samples are indistinguishable
from the standpoint of execution behavior. The second code sample is
just broken, because notify is called at an illegal time.
 
Reply With Quote
 
 
 
 
Robert Mark Bram
Guest
Posts: n/a
 
      05-31-2004
Hi Carl,

Thank you for letting me know that notifyAll() outside a synchronized block
is illegal.

> > Object sync;
> > ...
> > synchronized (sync){
> > // Do important stuff..
> > sync.notifyAll();
> > // Do more important stuff..
> > } // end synchronized


I found the answer I was looking for elsewhere (mental note: google first!):
- an object entering the synchronized code will block (something like an
implicit wait()) if it doesn't own the lock;
- code leaving the synchronized block will wake up one waiting thread, if
any (something like an implicit notifyAll();
- I don't need any notify calls in the synchronized block because Java
implicitly handles this.

Rob



 
Reply With Quote
 
xarax
Guest
Posts: n/a
 
      06-01-2004
"Robert Mark Bram" <none> wrote in message
news:40bbbbe1$0$3036$ ...
> Hi Carl,
>
> Thank you for letting me know that notifyAll() outside a synchronized block
> is illegal.
>
> > > Object sync;
> > > ...
> > > synchronized (sync){
> > > // Do important stuff..
> > > sync.notifyAll();
> > > // Do more important stuff..
> > > } // end synchronized

>
> I found the answer I was looking for elsewhere (mental note: google first!):
> - an object entering the synchronized code will block (something like an
> implicit wait()) if it doesn't own the lock;
> - code leaving the synchronized block will wake up one waiting thread, if
> any (something like an implicit notifyAll();
> - I don't need any notify calls in the synchronized block because Java
> implicitly handles this.


You only need the notify[All] calls when other threads
have called wait() on the synchronized object. If you're
intent is to create a critical section of code where only
one thread at a time may "do important stuff" to the object,
then you only need to synchronize on that object.

OTOH, if other threads are waiting for work to do (like
waiting on an event queue for a message object to arrive),
then you need wait() and notify(). A thread that wants to
pull a message from an event queue will wait() on that
queue (when the queue is empty) for another thread to call
notify() after it has placed a new message onto the queue.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Synchronized Block v.s. Synchronized Method Jerry Java 4 08-11-2010 02:34 PM
synchronized block in synchronized static method dmcreyno Java 9 06-27-2006 07:43 PM
Use of synchronized variables over synchronized methods? Pep Java 6 08-15-2005 01:29 PM
procs/blocks - blocks with procs, blocks with blocks? matt Ruby 1 08-06-2004 01:33 AM



Advertisments