jason-users Mailing List for jason

Thanks, it helped a lot.

Fabio Yoshimitsu Okuyama
ok...@in...


----- Original Message ----- 
From: "Rafael H Bordini" <R.B...@du...>
To: "Fabio Yoshimitsu Okuyama" <ok...@in...>
Cc: <jas...@li...>
Sent: Tuesday, May 31, 2005 10:50 AM
Subject: Re: [Jason-users] Environment Synchronization


>
> Hi Fabio,
>
> Yes, you need to worry about synchronisation. In the old
> days Jason used to do that automatically (the executeAction
> method was "synchronized"), but that turned the environment
> too much into a bottleneck of the system, so we now leave
> it for the programmer to handle that, i.e., to synchronise
> only at the points where changes are actually being made
> to the list of percepts. You can do something like:
>
> synchronized(getPercepts()) {
>   // change percepts here...
> }
>
> when you need to update the percepts. Having this kind
> of synchronisation greatly improves the performance of
> the environment.
>
> Version 0.7 which will be realeased in one or a couple
> of weeks, the mechanism used for individual and global
> percepts will be improved too, so you can synchronise
> on an angent's individual list of percepts rather than
> the global one, which can also make it more efficient.
>
> Hope that helps,
>
> Rafael
>
>
> Fabio Yoshimitsu Okuyama writes:
> > Hi,
> >
> >     I was programming an environment for Jason and the following doubt 
> > came
> >     out: On the implementation of the executeAction function, do I have 
> > to
> >     worry about synchronization??  Avoiding deadlocks or inconsistency 
> > due
> >     to multiple access on my environment data (getPercepts and 
> > executAction
> >     functions) is done by Jason or I have to implement some kind of
> >     lock-unlock on my environment? Is it something to worry?
> >
> > best regards,
> >
> > Fabio Yoshimitsu Okuyama
> > ok...@in... 

Hi Fabio,

Yes, you need to worry about synchronisation. In the old
days Jason used to do that automatically (the executeAction
method was "synchronized"), but that turned the environment
too much into a bottleneck of the system, so we now leave
it for the programmer to handle that, i.e., to synchronise
only at the points where changes are actually being made
to the list of percepts. You can do something like:

synchronized(getPercepts()) {
   // change percepts here...
}

when you need to update the percepts. Having this kind
of synchronisation greatly improves the performance of
the environment.

Version 0.7 which will be realeased in one or a couple
of weeks, the mechanism used for individual and global
percepts will be improved too, so you can synchronise
on an angent's individual list of percepts rather than
the global one, which can also make it more efficient.

Hope that helps,

Rafael


Fabio Yoshimitsu Okuyama writes:
 > Hi,
 > 
 >     I was programming an environment for Jason and the following doubt came
 >     out: On the implementation of the executeAction function, do I have to
 >     worry about synchronization??  Avoiding deadlocks or inconsistency due
 >     to multiple access on my environment data (getPercepts and executAction
 >     functions) is done by Jason or I have to implement some kind of
 >     lock-unlock on my environment? Is it something to worry?
 > 
 > best regards,
 > 
 > Fabio Yoshimitsu Okuyama
 > ok...@in...

Hi,

    I was programming an environment for Jason and the following doubt =
came out:
    On the implementation of the executeAction function, do I have to =
worry about synchronization??
    Avoiding deadlocks or inconsistency due to multiple access on my =
environment data (getPercepts and executAction functions) is done by =
Jason or I have to implement some kind of lock-unlock on my environment? =
Is it something to worry?

best regards,

Fabio Yoshimitsu Okuyama
ok...@in...