• 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

Confusion about Thread Behaviour

 
Ranch Hand
Posts: 51
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, In multithread application more than one thread can concurrently access and modify shared variable which may result in data race problems. Okey, lets do it practically



When i ran A1, i got data race problem and got output like
1 3 4 2 5 7 8 6 9 = First Run
1 3 2 4 5 6 7 8 9 = Second Run

so i add 'synchronized' keyword to the increment method in //Thread Implemention A and problem is fixed and now output is

1 2 3 4 5 6 7 8 9 (for multiple runs)

In case of A2 and A3 i ran the default implementation (without adding 'synchronized' keyword to increment method) and got the data race problem. i changed it and added ('synchronized)' keyword to increment method in
//Thread Implemention A and //Thread Implemention B but i still got the data race problem

2) What is the difference between A1 and A2 , does they both result in creating three threads ? I tried and from the output (by running A2 and A3) what i understood is that they both are not same ..!!
 
author
Posts: 23956
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kaxhif Khan wrote:
so i add 'synchronized' keyword to the increment method in //Thread Implemention A and problem is fixed and now output is

1 2 3 4 5 6 7 8 9 (for multiple runs)



Okay, but do you know why it worked? Keep in mind that the synchronized keyword isn't a magically statement that says "There is a race condition here. Fix it.". That keyword does something. What does it do? And how does it fix the race condition?


Anyway... hint ... in the examples, are the threads using the same synchronization lock?

Henry
 
Kaxhif Khan
Ranch Hand
Posts: 51
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, @Henry i do understand what the synchronize keyword do. It lock the critical section of code for an object (i.e. synchronized(this) or synchronize (ClassName.class) so at a time only one thread can access it. Critical section is the section of code where shared variables are modified.

Are the thread using the same synchronization locks in example ?

I may be wrong but lock is acquired on an object or a class i.e. (synchronize(this) or synchronize(ClassName.class). I add the 'synchronize' keyword to the instance method so lock is acquired on (this) ..!! Didn't this make locks same ?
 
Henry Wong
author
Posts: 23956
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kaxhif Khan wrote:Are the thread using the same synchronization locks in example ?

I may be wrong but lock is acquired on an object or a class i.e. (synchronize(this) or synchronize(ClassName.class). I add the 'synchronize' keyword to the instance method so lock is acquired on (this) ..!! Didn't this make locks same ?


As you know, every object can access itself via a this reference (from an instance method) -- so does that make every object the same as every other object? Of course not.

In your first example, the object locks are the same. In your later example, the object locks are not. And accessing them from two different reference variables (with the same name as this) doesn't make the objects the same.

Henry
 
Kaxhif Khan
Ranch Hand
Posts: 51
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ooops yeah ... Thanks alot i got it ...!!
 
And will you succeed? Yes you will indeed! (98 and 3/4 % guaranteed) - Seuss. 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