• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

run and start together

 
Ranch Hand
Posts: 238
1
Eclipse IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
If i have a synchronized method and two threads use the same instance to run the method ,but i run one thread by run(),and other by start().Does the synchronization of the method still prevents the threads from accessing the method at the same time?

Thanks...
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sudhanshu Mishra wrote:Hi all,
If i have a synchronized method and two threads use the same instance to run the method ,but i run one thread by run(),and other by start().Does the synchronization of the method still prevents the threads from accessing the method at the same time?

Thanks...


Well, when you call run method over a thread object, you don't start a new thread, but you simply invoke a method in current thread (e.g. main thread).

However, since your method is synchronized (over 'this'), yes, synchronization of method will prevent the threads from accessing method at same time. This is because even if one invocation is done by a thread started by 'start' method and another is done by current thread (i.e. run method), those two are still different threads, invoking a synchronized method on same object.

But please note, again, that you've actually spawned only one thread (the one on which you invoked start method). Invoking run method does not create a new thread.

I hope this helps.
 
Sudhanshu Mishra
Ranch Hand
Posts: 238
1
Eclipse IDE Fedora Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply,
but still have a confusion,silly though.If the thread is already going to lose the lock when it waits,then why in the first place give it the lock for object by synchronization?does synchronzation has really something to do with the waiting of thread,or is it meant for other code within the synchronized block?
I hope you understand my problem.
Please guide me through....
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sudhanshu Mishra wrote:Thanks for the reply,
but still have a confusion,silly though.If the thread is already going to lose the lock when it waits,then why in the first place give it the lock for object by synchronization?does synchronzation has really something to do with the waiting of thread,or is it meant for other code within the synchronized block?
I hope you understand my problem.
Please guide me through....


I guess Henry Wong has answered similar query by you here, but I'll still try to elaborate.

As he has said, synchronization is for making sure that the condition on which you are waiting must be touched by only one thread at a time. If wait/notify does not exist in synchronized block, then we cannot guarantee that our code will be in 'synch'.

e.g. Let us take a producer-consumer example. Let us assume that Java allows wait and notify without synchronization.

Now, here, since there is no synchronization, assume this scenario:
1) queue is empty
2) consumer reaches at line 7
3) producer starts, adds an object, notifies and gets out of the method
4) consumer starts to wait. It'll wait forever (unless some other producer wakes it up).
Thus, we can see our code is out of sync. This is just one example. Weird things can happen even after wait/notify (e.g. two threads simultaneously consuming same object and so on).

Now, check out the synchronized code:
Here, if scenario occurred similar to previously mentioned, we are still safe:
1) queue is empty
2) consumer reaches at line 10
3) producer is still not inside the synchronized block
4) consumer reaches at line 11, goes in waiting state and releases the lock
5) producer enters in synchronized block, adds a queue and notifies
6) since producer is finished, consumer again gets the lock
7) after line 11, consumer checks the while condition. it is now false and loop is broken
8) consumer goes to line 13, consumes the object.

This way, we are always sure that no two threads exists simultaneously in critical section.

I hope this helps.
 
Politics n. Poly "many" + ticks "blood sucking insects". Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic