JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net

The open source
grid computing

 Home   About   Features   Download   Documentation   On Github   Forums 
June 04, 2023, 08:26:30 PM *
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: Thread Safety?  (Read 2332 times)


  • Guest
Thread Safety?
« on: December 21, 2015, 08:36:14 AM »

Hello, I have implemented the JPPF grid into my project in order for it to run at a much faster rate. However, my project does include outside libraries that I have to call through my task class. My data output is continuously incorrect and I have realized that it is most possibly because my classes are not thread safe. Is there any way to modify the task and application runner class so that it can run on multiple threads without having data corrupted? Thanks!


  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2272
    • JPPF Web site
Re: Thread Safety?
« Reply #1 on: December 25, 2015, 10:58:51 AM »

Hello Jim,

Thread-safety is going to be up to the code in your tasks on the node side, and up to your application code on the client side. If the outside libraries you use are not thread safe, you will need to synhronize their invokcations among tasks, or use some kind of locking mechanism to achieve thread-sfatey. Synchronizing each outside API call individually may not be thread safe either, for instance if the outside library keeps a global state, as with static variables. Thus, your tasks should implement a pattern similar to this:

Code: [Select]
public class MyTask extends AbtsractTask<String> {
  private static final Lock GLOBAL_LOCK = new ReentrantLock();

  public void run() {
    // part of the code not using 3rd-party libraries

    // part of the code that uses 3rd-party libraries
    try {
    } finally {

    // part of the code not using 3rd-party libraries

Of course, this means that potentially large chunks of the processing time will not be performed in parallel, which will impact the overall performance. Since this locking pattern applies at the individual node level, you could mitigate by having more nodes with less processing threads each. For instance, instead of having 1 node with 4 processing htreads on each machine, you could start 2 nodes with 2 threads each, or 4 nodes with 1 thread (in which case locking is possibly no longer necessary), etc ...

Pages: [1]   Go Up
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at Fast, secure and Free Open Source software downloads