Race condition when updating percepts?

[mindcrime]

Folks:

Working on another exercise from the PMASIAUJ book, and ran into something that confused me initially. I think I get it now, but just wanted to confirm.

Briefly, I am working on another variation of the Vacuum Cleaner problem. In this version, I put multiple vacuum cleaner agents and have them move randomly about the room until all the squares are clean. Not the most efficient protocol, but it works. :-)

Anyway, in my AgentSpeak code I had plans for two possible conditions: numDirty > 0 and numDirty == 0. No other state should be possible, so I made my AgentSpeak code as follows:

vcleaner.asl

// Per Jomi's suggestion, start with an initial goal of !cleanroom
!cleanroom.

@c1 +!cleanroom : numdirty(X) & X > 0 <- .print( "cleaning room!" ); move_random; suck; !cleanroom.
@c2 +!cleanroom : numdirty(X) & X == 0  <- .print( "Done" ); .stopMAS.

And while this did work (all the squares were eventually cleaned) I noticed some errors in my log that seemed to indicate a case was happening where a plan was needed to represent the case where there was no numdirty percept at all. Considering that this is a case I thought impossible, I was a bit confused.

I added an explicit plan for that case with a .print("NOP"). just to track what was happening and realized that I was actually getting quite a few NOP lines in my logs. Weird.

A hunch led me to re-examine this code:

Env.java

    /* Update the agent's percepts based on the current state of the World Model */
    void updatePercepts() 
    {
    	        
        // clear the percepts of the agents
    	clearPercepts();
        
        int numDirty = get_num_dirty();
        String dirtyTemp = "numdirty(" + numDirty + ")";
    	logger.info(  "adding " + dirtyTemp + " percept" );
        Literal lDirty = Literal.parseLiteral( dirtyTemp );


       addPercept( lDirty );    	
    }  

Knowing that get_num_dirty() is a relatively expensive operation the way I coded it, and considering that it was between clear_percepts() and add_percept() I thought "Aaah, a race condition. The agent is trying to proceed after I called clear_percepts() but before I insert the num_dirty percept."

So I recoded that method as follows:

Env.java

    /* Update the agent's percepts based on the current state of the World Model */
    void updatePercepts() 
    {
    	int numDirty = get_num_dirty();
        String dirtyTemp = "numdirty(" + numDirty + ")";
    	logger.info(  "adding " + dirtyTemp + " percept" );
        Literal lDirty = Literal.parseLiteral( dirtyTemp );
        
        // clear the percepts of the agents
    	clearPercepts();
        addPercept( lDirty );    	
    }  

Now I don't call clear_percepts until all the other work is done and I can immediately call add_percept(). And sure enough, after making this change, all the NOP lines in my logs disappeared. So problem solved.

But I find myself wondering, is this - strictly speaking - always a potential race condition that's present? And as such, should I make it a point to always have code in my AgentSpeak plans to explicitly deal with any "missing percept" scenarios - even if said plan does nothing to log, or retry? Or is there a way to make this fully deterministic such that I can be 100% sure (well, as close to 100% as possible anyway) that the "missing percept" thing can never happen?

I did try adding

executionControl: jason.control.ExecutionControl

in my .mas2j file but that had no effect one way or the other.

It also occurs to me that I'm using num_dirty as a sort of "global" variable here, by not using individualized perception. I suspect this kind of problem would be less likely to happen if I were using individualized perception. Does that sound right? And would you all say that there's a general preference one way or the other in terms of favoring individualized perception over "global" perception? Or am I totally missing the boat on this?

Full source code can be found here.

Thanks!

[jomifred]

Interesting discussion!

For a possible solution, I'd go for a lock to change/consult the env. state. For instance, in your env. class, override the getPercepts with a lock so that no agent is getting perception while it is being changed:

    Object myLock = new Object();
    public Collection<Literal> getPercepts(String agName) {
        synchronize(myLock) {
             return super.getPercepts(agName);
        }
    }

then surround the code that changes the environment by synchronize(myLock) { .... }

In case you implement it, let us know if it works.

[mindcrime]

Good point. Just slapping a 'synchronized' in there briefly crossed my mind, but I thought that might be overkill. I will continue to experiment with this though.