File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Threads and Synchronization and the fly likes Multithreading: Usage scenarios Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Multithreading: Usage scenarios" Watch "Multithreading: Usage scenarios" New topic
Author

Multithreading: Usage scenarios

Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Hi,

I would like to know the various scenarios in which multithreading would be useful.

Should multithreading be used when:

1. All required data is read in memory and a lot of processing is to be done on it
2. Or should the data reading in (1) be done with threads too?
3. Or Should threads be used for different independent tasks such as buffering a video while playing it back simultaneously?

Thanks
Istvan Kovacs
Ranch Hand

Joined: May 06, 2010
Posts: 100
Multithreading could be used for a number of purposes.
  • distribute work on a large dataset between CPU's (each thread performs the same kind of work)
  • keeping the UI responsive while an operation is carried out in the background (different kind of work)
  • even in a single-CPU case, one thread may be performing I/O; another one may use the CPU while the 1st one is blocked on I/O
  • threads may be a modelling tool: if the tasks you have to do are independent, it's better to use a thread for each - suppose you're printing a bunch of documents; you need to feed the printer, but for example react to mouse actions to allow the user to cancel, and keep a clock ticking on the UI. You could do it with one thread (loop: send 1000 bytes to printer, update clock, check mouse...), but it would be a nightmare.
  • Vedhas Pitkar
    Ranch Hand

    Joined: Jan 27, 2001
    Posts: 445
    Istvan Kovacs wrote:Multithreading could be used for a number of purposes.
  • distribute work on a large dataset between CPU's (each thread performs the same kind of work)




  • Considering the above case, is it not similar to multiple requests to a web server? If multiple threads perform same kind of work (process a dataset) will the performance not be affected?
    Istvan Kovacs
    Ranch Hand

    Joined: May 06, 2010
    Posts: 100
    Vedhas Pitkar wrote:
    Istvan Kovacs wrote:Multithreading could be used for a number of purposes.
  • distribute work on a large dataset between CPU's (each thread performs the same kind of work)



  • Considering the above case, is it not similar to multiple requests to a web server? If multiple threads perform same kind of work (process a dataset) will the performance not be affected?


    No, that's actually another scenario, but you are absolutely right, serving multiple requests is a valid case.

    The difference is granularity:
    When serving multiple concurrent requests with one thread per request, even if the request involves lots of work, or activities that could be done in parallel (e.g. retrieving data from multiple sources that have to be combined to serve the request), you only use a single thread, even if load is low and several CPUs sit idle. What I meant by splitting work on a large dataset / long calculation between threads was to employ several threads to serve a single request. You can combine the strategies, of course: the application server uses a single thread to serve each incoming request, and they all use a big, shared thread pool for calculations that can be performed faster using multiple threads.
    Richard Golebiowski
    Ranch Hand

    Joined: May 05, 2010
    Posts: 213

    You need to look at each case and determine if multithreading is appropriate or not.

    So for 1, I would say that in this case it would be useful especially if the processing is independent of the data as a whole. An example of this would
    be having a group of customers to calculate a bill for service. Each customer is independent so a customers bill dose not depend on another customers bill.

    For 2, maybe yes, maybe no, and probably not. Gains in multithreading generally come from processing.

    For 3, yes, because you need the data available for playback so the playback is not choppy.

    Where I have used mulithreading are:
    1) FTP server where each client connection has it's own thread.
    2) Calculating a large number of payments where each calculation is independent of the other payment calculation. If it was a small number of payments, I probably wouldn't have done it mutithreaded.
    Sergey Babkin
    author
    Ranch Hand

    Joined: Apr 05, 2010
    Posts: 50
    Istvan Kovacs wrote:Multithreading could be used for a number of purposes.


    There is also the convenience. When you do multiple parallel things in a single thread, you have to switch between them manually, switching when the current processing hits a block. Programming with threads saves this manual swithing: the thread library takes care of it, saving the contexts and restoring and restarting them as needed. So even on a single-CPU machine this can simplify the program a lot (or not :-)
    Vedhas Pitkar
    Ranch Hand

    Joined: Jan 27, 2001
    Posts: 445
    Thanks all for your informative responses.

    We are facing a performance issue where the introduction of multithreading is slowing down the application.

    The scenario is somewhat like:
    There's a method methodA() which does a lot of processing(hitting database tables for CRUD, writing to log files). Since this takes time, we tried to do it in parallel. But the multithreaded version takes more time than the normal version of the code.

    The code is like


    Any inputs would be appreciated.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3947
        
      17

    Vedhas Pitkar wrote:We are facing a performance issue where the introduction of multithreading is slowing down the application. ...(hitting database tables for CRUD, writing to log files). ...



    You have to find where the bottleneck is and isolate. You only gain as much out of threading as you have resources. From the information you provided your resources are:
    1) Processors
    2) Memory
    3) Disk
    4) Database connections

    The first thing to do would be to run the single threaded code and watch your processor(s) - How many processors are you running on, and how much of the time is the processor spiked? You only will gain from multi-threading if you have down-time in your processors (ie you have more than one, or the processor never spikes or has significant times between usage spikes). If your single threaded model already uses all of your processing power adding more threads just adds the overhead of context switching without the benefit of more efficient processor usage.

    Then comes memory. Do you have enough memory on your system to run multiple threads at the same time? Or will each thread need to compete for memory as a resource, requiring more garbage collection and waiting for available space?

    Writing to disk in a multi-threaded environment is rarely more efficient than doing it in a single threaded environment. You typically have only one disk with one write head, and so you spend time in each thread waiting for the write head to get to the point were it needs to write the file for that particular thread. This isn't necessarily true if your file writes are condensed together into one particular chunk of executing code so that other threads can take advantage of the free processor time, but is a problem when there is ongoing writing for all threads. So for your log writing, you might consider pooling the log writes into a single thread. Each working thread posts a log line to some queue, and you have a single log writing thread which puts the queue onto disk.

    Databases connections are a resource all their own. If you share a connection between threads then you have to wait for the connection to be open to proceed, slowing things down. If you have a connection per thread then you can stress your network and the database, again slowing everything down. Your best bet here is to use a connection pool which is balanced for the number of threads you expect to run and the number of concurrent requests your DB will have available. Getting the correct value can be a thing of trial and error depending on how many apps the DB is used for.


    Steve
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Multithreading: Usage scenarios
     
    Similar Threads
    NX: Synchronization of file access & no caching
    start() and join() in thread
    Timers Question
    Synchronized block
    Struts 1 - Multibox Question