Forums Register Login

Parallel calls to a static class

+Pie Number of slices to send: Send
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!
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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) ?
1
+Pie Number of slices to send: Send
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.
1
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
1
+Pie Number of slices to send: Send
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.
1
+Pie Number of slices to send: Send
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.
2
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
Yes, I see what you mean. The method is executed with multiple stack frames in different places.
What I don't understand is how they changed the earth's orbit to fit the metric calendar. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 5678 times.
Similar Threads
SimpleDateFormat is not thread safe
Thread Pools
Could my program fail with race condition by concurrent threads in a multi thread environment?
threads and static methods
Singleton and Thread Safety
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 10:56:09.