Menu

#40 Configuration is not thread safe

JGAP 3.2
closed-fixed
Klaus
7
2007-06-07
2007-05-16
No

Hi,

We're thinking of (and prototyping with) using JGAP in a server environment where many clients may call in to our server which uses currently JGAP to find a solution to a problem using a GA.

The problem I have is that I get an exception saying that:
"Fitness evaluator has already been set differently.
If you want to set or construct a configuration multiple times, please call static method Configuration.reset() before each setting!"

I can work around this for now as we only have a requirement for a single GA solution in the project.

Looking at the JGAP code I notice there is a heavy dependency on static data such as System properties. In a server environment this is not ideal, especially if we wanted to use multiple GA solutions.

If multiple threads tried to create an instance of the Configuration object at the same time, there is likely to be conflicts.

My work around for now is to make the Configuration object static, but if we ever wanted to use multiple GA solutions in our project this would not work. In that case I would synchronize on the Configuration class instance, call reset and then create my Configuration object inside the synchronized block. I haven't investigated far enough to determine if this would actually be enough to work (i.e. is the Configuration class thread-safe once it has been instanciated?), but I will cross that bridge if I get to it.

The "fix" I would like to see to this "bug" is that the Configuration class should be thread safe, i.e. there should be no need to call static methods in order to create new instances of Configuration and no there should be no dependencies on any other static data, e.g. system properties.

Thanks in advance if you decided to change the code to support this.

Regards,
Brindy

Discussion

  • Klaus

    Klaus - 2007-05-19
    • priority: 5 --> 7
    • assigned_to: nobody --> klausikm
     
  • Klaus

    Klaus - 2007-05-19

    Logged In: YES
    user_id=722855
    Originator: NO

    Brindy,

    good point! I can completely follow your argumentation. Avoiding static methods was a main concern when redesigning JGAP some versions ago.

    My initial suggestion to solving your problem is writing a test application with, say, 10 threads, each working with a different configuration. The main goal is to ensure that JGAP can handle this scenario. If not we’ll find a way solving the problem. If yes we’re done.

    Best
    Klaus

     
  • Christopher Brind

    Logged In: YES
    user_id=140136
    Originator: YES

    Hi Klaus,

    Thanks for the reply.

    The problem has already manifested itself with the message "Fitness evaluator has already been set differently. If you want to set or construct a configuration multiple times, please call static method Configuration.reset() before each setting!".

    I am happy to live with a work around I have in place for now, it seems to work fine once the Configuration object is used statically, but of course that means I can only ever have one GA solution in my application. I just thought I would let you know so that it can be improved in future versions.

    Thanks again, JGAP is very good.

    Cheers,
    Brindy

     
  • Klaus

    Klaus - 2007-05-19

    Logged In: YES
    user_id=722855
    Originator: NO

    Hi Brindy,

    thanx for your quick reply!
    After a try I think that JGAP's configuration is thread safe in the sense that you can have different threads, each with a single configuration.
    Your problem may be something different than having multiple threads, each with a different configuration I think.
    This is because JGAP's configuration object relies on thread IDs to make it possible having a unique configuration for different threads.
    Thus, when you get the error you described, you are accessing the configuration from the same thread multiple times, i.e. you are trying to set a property of the same configuration multiple times. This is forbidden intentionally as it may lead to inconsistent states.

    So what you could do to be on the clean side is use a new (thus different) thread for each GA you are going to evolve. Then you have (hopefully) completely independent configurations!

    Could you agree with that or is this not a proper way for you to go?

    Best

    Klaus

     
  • Christopher Brind

    Logged In: YES
    user_id=140136
    Originator: YES

    Hi Klaus,

    I see that how that would work, but I'm struggling to see why System properties are being used at all for anything other that static configuration properties. They shouldn't be being used to represent data for instances of classes.

    Also, is there something that clears the system properties out when the GA is finished? All I could find is reset() which sets them to blank, but does not remove them.

    In a server environment, which is potentially handling hundreds of clients and thousands of requests (each with their own thread, or maybe even sharing a thread pool), I can see the system properties getting somewhat cluttered.

    I realise that server environments may not have been considered when JGAP was initially designed.

    Thanks again.

    Cheers,
    Brindy

     
  • Klaus

    Klaus - 2007-05-19

    Logged In: YES
    user_id=722855
    Originator: NO

    HI Brindy,

    OK, if System properties are your point, then it's something different.
    They were introduced into JGAP because a VM-wide store was needed. This store holds a reference to the JGAP Factory as well as config-specific properties.
    Resetting those properties is a valid aspect you mention. This should be introduced with JGAP. I'll do that asap.
    What would be your suggestion instead of using system properties? Do you imagine something like a static variable that is accessed in a thread-safe manner or something different? Initially I wanted to avoid static variables, thus the system properties' thingie...

    Best

    Klaus

     
  • Christopher Brind

    Logged In: YES
    user_id=140136
    Originator: YES

    Hi Klaus,

    I'm not entirely sure what it is you're trying to do with the system properties. They are fine to use in order to specify the names of default factories and general configuration like that, but they shouldn't be used to store instance specific information. i.e. they are used to pass in information to the VM, but really shouldn't be set in the VM by application code (personally I think they should change this so you can't do that!).

    For instance, I should be able to do this in a single block of code, if I wished (not that I would):

    Configuration conf1 = new Configuration();
    conf1.setFitnessFunction(myFitnessFunction);

    Configuration conf2 = new Configuration();
    conf2.setFitnessFunction(myOtherFitnessFunction);

    However, setting of the fitness function on conf2 throws an exception saying that I need to call a static method before creating an new instance of the class and this is due to both instances referencing the same static data.

    I'm afraid I'm not really sure what to suggest as I have only had a look at the code for Configuration and a few other high level classes, so I can't be sure where else JGAP has a dependancy on the static variables. I will endeavour to have a more detailed look over the coming week and draft up a few suggestions, if you don't mind?

    Thanks,
    Brindy

     
  • Klaus

    Klaus - 2007-05-19

    Logged In: YES
    user_id=722855
    Originator: NO

    Hi Brindy,

    OK, I understand better what you want to do. Although I can only assume what your point with the System properties is, a solution for accomplishing what you want to do with the single block of code given is:
    Configuration conf1 = new Configuration("ID1","informal name");
    conf1.setFitnessFunction(myFitnessFunction);

    Configuration conf2 = new Configuration(,"ID2","another informal name");
    conf2.setFitnessFunction(myOtherFitnessFunction);

    The only relevant change is the id passed to the constructors. It must be unique throughout all of the configuration objects you use. I added a test (testConstruct_3) in org.jgap.ConfigurationTest to expose the functionality. To be honest there currently is no use case for this function so I hope it works in detail. Maybe you could give me some feedback if it does for you :-)

    Of course further proposals are welcome any time!

    Best

    Klaus

     
  • Klaus

    Klaus - 2007-06-07

    Logged In: YES
    user_id=722855
    Originator: NO

    In new package org.jgap.impl.job there is a "proof" that configuration is thread-safe.
    I'm closing this now. If there are open issues please call back.

     
  • Klaus

    Klaus - 2007-06-07
    • status: open --> closed-fixed
     

Log in to post a comment.