Hi Mayuresh,
I believed sockets, RMI or CORBA may be used for multiprocessing.
You're absolutely right. These technologies could be used for communication between processes (even on different machines). There are surely a lot of other possibilities like XML-RPC for example. Almost any of these communication solutions have their own advantages or disadvantages. So it depends on your detailed requirements what could be a solution for you. RMI for example is one preferred way to communicate between Java applications but it won't be the best idea if you have applications running with different programming languages.
In general, with multiple threads there's obviously no need for such technologies because threads have direct access to shared data which usually means less overhead. That's why I recommended to improve the application to run with only one process but multiple threads which is usually more resource friendly.
Originally my idea is the parent process will provide a common UI, spawns multiple processes, then divide userlist selected in UI and pass separate lists to individual processes.
There's basically nothing wrong with this concept and the separation of concerns! In my opinion it should be even more efficient if you can modify your application to use the same modular concept but with multiple threads instead of multiple processes. That should make the communication logic between modules much easier and the overall performance should be better.
It's a completely different thing if your problem domain is too difficult to solve for a single machine. If you really have to use multiple machines for performance reasons, i.e. you have to create a distributed system, then there's (almost) no other way than to use inter-process communication technologies to synchronize and communicate between different processes running even on different machines. But to write a distributed system from scratch (and to get it right!) will most probably be overkill for the average application
Existing application is anyway doing good, however it proved it may work even better, I will give thoughts on all possible approaches.
That's for sure a good starting point if your application is already performing well. As I already said I suspect that you're only problem could be some technical details which prevent your application to scale up to run efficiently with even more threads. I'm not an expert here but a good understandable example are collection classes. If you share data structures like collections between threads there are some collections which are better suited for concurrent access and some are not. Some only scale up well up to a certain amount of threads accessing it and then degrade in performance.
And that's exactly what
you should try to find out. Somewhere there's a bottleneck in your application. Besides a bottleneck inside the application itself or with external resources like a database or filesystem there's no obvious reason why multiple processes (running on the same machine) should scale better than an equivalent application running with one process and multiple threads. Using a profiler to locate such a bottleneck would be the best approach to find a starting point for optimization.
A excellent resource for details are the
online articles and the book of Brian Goetz. He's definitely what I would call an expert on Java concurrency. Unfortunately this is a quite difficult topic (in my opinion) but it will definitely become increasingly important for writing efficient applications on modern multicore machines.
Marco
