Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threading question

 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have two simple programs that do the same thing. One threaded one not. I'm doing something wrong in the threaded one as it takes , on average , 4 times longer to do the same ting as the unthreaded version. I'm running two threads on a macbook pro. The activiy monitor show both cores going really hard(95%). Can someone point me in the right direction?
Here is the threaded version.
Main:

NumberGenerator:


here is the unthreaded version:


 
fred rosenberger
lowercase baba
Bartender
Pie
Posts: 12097
30
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am by no means an expert on this, so everything I say may be wrong...

why do you think making it multi-threaded will speed things up? threads are not a magic bullet. My understanding is that they can help if your CPU is idle a lot while waiting for things - a message, a printer to be available, user input, etc. But if all your program does is use the CPU, using threads can slow it down, as it now has to manage all the thread stuff in addition to doing the work.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

why do you think making it multi-threaded will speed things up?


Because I have a two core machine, I can have two threads running at the same time. The activity monitor on the mac actually shows a difference between the tow programs. I've tried this on a 16 core machine as well, It is also slower running threaded v. unthreaded.
 
Stephan van Hulst
Bartender
Pie
Posts: 5585
53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because multi-threading takes extra overhead, and there's no way the task you're performing in your example is going to justify the overhead of more than one thread.

You should strive to make as much as possible run in a single thread, because it significantly simplifies your program.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Because multi-threading takes extra overhead, and there's no way the task you're performing in your example is going to justify the overhead of more than one thread.



Really?

The unthreaded version takes around 5 minutes to run and drives the cpu at about 50 %.
 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, Math.random() could be a source of a lot of contention in this scenario, I guess.
If you supply each thread with its only random generator (java.util.Random) I believe that would cut the synchronization overhead.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Well, Math.random() could be a source of a lot of contention in this scenario, I guess.
If you supply each thread with its only random generator (java.util.Random) I believe that would cut the synchronization overhead.


That's it!. Just changed the run(). and now it finishes in seconds. Thanks.

 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The increment of the static numberOfMatches member isn't thread-safe though.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I know how to fix that...
Thanks.
 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Feel free to share ;)
Also, yielding inside the loop would increase fairness.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To make it thread safe i think I could make a method like:


In this case would increasing fairness increase overall speed?

This is just a Rube Goldbergian way to generate lottery numbers and learn about threads.

 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
john sayeau wrote:To make it thread safe i think I could make a method like:


In this case would increasing fairness increase overall speed?

This is just a Rube Goldbergian way to generate lottery numbers and learn about threads.



Afraid that's still not safe.
You're now locking on the intrinsic lock associated with the NumberGenerator instance.
Of which there are two. The field is static, which means its not associated with any particular instance.

Increasing fairness would not do anything to increase overall speed in this scenario.
 
john sayeau
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll figure it out. Lots to learn. Just starting with Threading.
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java 5 introduced a lot of new classes that tackle problems related to concurrency. They can be found in the java.util.concurrent package. One of the classes which can be found in the java.util.concurrent.atomic package can be used to solve one of your issues here.
 
Campbell Ritchie
Sheriff
Posts: 48652
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No longer a "beginning" topic. Moving discussion to our threads forum.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic