🚀 go-pugleaf

>   Si, lo que dices esta muy bien, pero he tenido la oportunidad de "destrozar" el
> codigo de una simulacion con una idea similar a la mia y la hacian como tu dices,
> creando un hilo que se encargase de la simulacion y aquello era un desastre. Habia
> una dessincronizacion entre por donde iba el Thread y por donde iba el Paint que no
> habia manera de entenderla.

�Qu� quieres decir con eso de la "desincronizaci�n"? Solo debes tener cuidado de que el
m�todo paint() no modifique datos generados por el thread de la simulaci�n. Tambi�n
estar�a bien que el acceso a dichos datos fuera a trav�s de m�todos de acceso
sincronizados, de forma que paint() siempre tuviera la versi�n m�s actualizada de los
datos. Es decir, si tienes tres variables importantes (por ejemplo: X, Y y Z) que debes
mostrar en pantalla, haz que el paint() lea los valores mediante los m�todos:

synchronized int leeX(){
    return X;
}

synchronized int leeY(){
    return Y;
}

etc...

Para modificar esos valores, puedes tener m�todos:

synchronized void escribeX(int x){
    this.x = x;
}

etc...

As� puedes tener la seguridad de que ambos hilos de ejecuci�n est�n siempre
perfectamente sincronizados.

Si el n�mero de variables que debes controlar es muy grande y quieres que �stas se
modifiquen todas de golpe (sin que los hilos se interrumpan unos a otros), puedes
sincronizar bloques de c�digo:

public void run(){
    /* c�digo de la simulaci�n */
    ...
    /* vamos a modificar el estado del objeto de forma "at�mica" (indivisible) */

    synchronized(this){
        x = ...
        y = ...
        z = ...
    }
    /* resto de la simulaci�n */..
}

public void paint(Graphics g){
    int xx,yy,zz;
    synchronized(this){
        xx = x;
        yy = y;
        zz = z;
    }
    /* Ya podemos usar los valores de xx,yy y zz
        y dibujar todo en pantalla */
    }

Un saludo.

Chano.