Win a copy of Murach's Java Programming this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Parallel calls to a static class  RSS feed

 
Chris Sadowski
Greenhorn
Posts: 14
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have a likely silly questions but having trouble finding a proper answer to it.

If I have a large number of threads working simultaneously, each of them wanting to perform a heavy calculation. It makes sense that his calculation is just a single static function in some class I could call with different parameters from each of the threads. However, since (to my understanding) static functions cannot have many instances, will I run into a bottleneck where I'm trying to call the same method from all the threads?

(the calculation is completely independent per thread, so in essence I don't even need it to be synchronized, so I would like for all threads to make this calculation in parallel.. would this work while sharing a static call? )

Thanks!
 
Henry Wong
author
Sheriff
Posts: 23260
124
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chris Sadowski wrote:However, since (to my understanding) static functions cannot have many instances, will I run into a bottleneck where I'm trying to call the same method from all the threads?


Please explain why you mean by this? Static method does not have a this instance, but, other than that, it is little different than other methods.

And what "bottleneck" are you referring to?

Henry
 
Chris Sadowski
Greenhorn
Posts: 14
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe I have the wrong understanding of static methods. As far as I understand its an instance-less, effectively block of memory, that can perform a certain parameterized computation without a need to create an object.   If I have multiple objects owned by each thread and call on them to perform a calculation, they can obviously do it in parallel. If I have a bunch of threads calling a static method of some class at the same time, won't they physically block each other (as they would if I only had one object with a non-static function that I'm calling from many places) ?
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37051
507
Eclipse IDE Java VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Chris,
While there is only one copy of static data, this logic doesn't apply to methods. Many threads/callers can be calling the same static method at the same time. They don't wait on each other.

If you wanted to limit the calls so they *couldn't* run in parallel, you'd need to add the word "synchronized" to the method. But by default, methods do what you want and there is no bottleneck.
 
Tony Docherty
Saloon Keeper
Posts: 3262
80
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First of all using multiple threads doesn't necessarily mean all the threads will be working simultaneously, that depends on the number of processor cores you have. If you have one single core processor (rare these days) only one thread will be running at any given moment. Java uses time slicing so one thread will run for a certain amount of time and then control will be passed to the next thread and so on. This of course may mean the total task runs slower than if it was done sequentially on a single thread as there is the overhead of thread switching to consider.

However, assuming you have multiple cores so at least some of your threads are running simultaneously then no the static method won't be a bottleneck unless it is synchronised or makes a call to something that is synchronized or uses a resource that blocks etc.

You do, however, need to make sure your static method is thread safe or all sorts of strange things may happen.
 
Junilu Lacar
Sheriff
Posts: 10929
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing to note: concurrency is not parallelism -- it doesn't matter that the speaker in that video, Rob Pike, is saying that in the context of the Go programming language, the same thing applies to Java and any other language in general.

That said, concurrency issues only arise when you share access to objects across multiple threads.  If the static method deals ONLY with objects that it creates or have been passed in as parameters from methods that created those objects and didn't provide access to those objects in a wider scope like as a class variable, then your static method should be thread safe. Again, thread safety is only an issue when data can be accessed by multiple threads. Local variables are thread safe.
 
Campbell Ritchie
Marshal
Posts: 54886
155
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Each thre‍ad has its own stack, so you would expect there to be a copy of the static method on each threa‍d's stack. So you have one Class<Foo> object which has the representation of the code for the methods, on the heap, and many copies of the method on the different stacks.
I can't see that causing any problems or bottlenecks. Local variables will be confined to their own copies of the methods and therefore don't need synchronisation.

This discussion would fit better in our Threading forum: moving.
 
Chris Sadowski
Greenhorn
Posts: 14
2
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the really quick and to the point replies!

Campbell Ritchie wrote:Each thre‍ad has its own stack, so you would expect there to be a copy of the static method on each threa‍d's stack.


Ah, that is exactly the piece of information I was missing in my understanding, and it makes perfect sense too.
 
Junilu Lacar
Sheriff
Posts: 10929
158
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Each thre‍ad has its own stack, so you would expect there to be a copy of the static method on each threa‍d's stack. So you have one Class<Foo> object which has the representation of the code for the methods, on the heap, and many copies of the method on the different stacks.
I can't see that causing any problems or bottlenecks. Local variables will be confined to their own copies of the methods and therefore don't need synchronisation.

This discussion would fit better in our Threading forum: moving.

That's not technically correct either. Program code is not duplicated. When a class is loaded in memory, it is the single copy of the code that gets executed. It may help to visualize it as though you had multiple copies of the code but that's not actually what happens under the covers. Juggling of stack frames, addresses/pointers, and the instruction pointer is what actually happens. This is part of the reason why concurrency issues are about shared data, not shared code.
 
Campbell Ritchie
Marshal
Posts: 54886
155
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I see what you mean. The method is executed with multiple stack frames in different places.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!