Discussion :

[j0o0]

Bonjour a tous,

Je me demandais un truc a propos des AsyncTask : est-il thread-safe d'avoir une classe heritant d'AsyncTask et qui contient des variables membres utilisees dans doInBackground et onPostExecute ?

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static class RequestTask extends AsyncTask<String, Void, Document> {
 
    private Object mObject;
 
    @Override
    protected Document doInBackground(String... params) {		
        Document result = null;
        // ...
        mObject = ...;
        return result;
    }
 
    @Override
    protected void onPostExecute(Document result) {
        if (mObject != null) {
            // ...
        }		
    }
 
}

Ca fonctionne, mais je ne pense pas que cela soit tres propre, qu'en pensez-vous ?
Merci !

[_Xavier_]

C'est une classe "static", une instance pouvant être partagée par plusieurs threads pouvant ) leur tour modifié tes variables : ton asyncTask n'est pas thread safe.

[adiGuba]

Salut,

C'est une classe "static", une instance pouvant être partagée par plusieurs threads pouvant ) leur tour modifié tes variables : ton asyncTask n'est pas thread safe.

Non : pour une classe, le static indique seulement que la classe n'es pas lié implicitement avec une instance de la classe conteneur... C'est tout !
Cela n'a aucun impact sur le coté thread-safe...



Je ne connais pas bien la plateforme Android, mais AsyncTask semblent être un genre de SwingWorker amélioré...


Ton attribut private mObject n'est accédé que par deux méthodes : doInBackground() et onPostExecute(). Et d'après la documentation on est sûr que ces deux accès ne seront pas manipulé en parallèle (onPostExecute() est exécuté à la fin de doInBackground()).

Donc il n'y a aucun problème à ce niveau là.


Le seul problème qu'il peut y avoir, et qui est assez difficile à mettre en évidence, c'est que la JVM peut "optimisez" les accès aux champs pour un thread et ne pas s'apercevoir qu'il a été modifié depuis un autre thread.

Pour éviter cela, il faut déclarer l'attribut en volatile.


a++

[j0o0]

Merci adiGuba, c'est le genre de reponse claire et precise que j'apprecie beaucoup !

[_Xavier_]

Salut,


Non : pour une classe, le static indique seulement que la classe n'es pas lié implicitement avec une instance de la classe conteneur... C'est tout !
Cela n'a aucun impact sur le coté thread-safe...

Je n'ai pas dit qu'une classe static n'est pas thread-safe. C'est quand ses variables peuvent être modifiées dans différents threads qu'elle le devient. (Ok c'est aussi valable pour un objet non static)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
   @Override
    protected Document doInBackground(String... params) {		
        Document result = null;
        // ...
        mObject = ...;
        return result;
    }
 
    @Override
    protected void onPostExecute(Document result) {
        if (mObject != null) {
            // ...
        }		
    }

Il n'est pas possible qu'on se trouve dans une situation où dans un thread on fait doInbackground() (en modifiant mObject) et dans un autre on fait (onPostExecute() (où l'on teste mObject) ?

Le seul problème qu'il peut y avoir, et qui est assez difficile à mettre en évidence, c'est que la JVM peut "optimisez" les accès aux champs pour un thread et ne pas s'apercevoir qu'il a été modifié depuis un autre thread.

On peut être dans cette situation et être thread-safe ?

[adiGuba]

Je n'ai pas dit qu'une classe static n'est pas thread-safe. C'est quand ses variables peuvent être modifiées dans différents threads qu'elle le devient. (Ok c'est aussi valable pour un objet non static)

Donc le mot clef static n'a rien à voir là dedans

Il n'est pas possible qu'on se trouve dans une situation où dans un thread on fait doInbackground() (en modifiant mObject) et dans un autre on fait (onPostExecute() (où l'on teste mObject) ?

Ces deux méthodes étant protected on ne peut pas les appeler directement. Et sauf erreur on ne peut exécuter la tâche qu'une seule fois

On peut être dans cette situation et être thread-safe ?

Si tu n'utilises pas volatile tu n'est pas sûr du comportement. Donc tu pourrais ne pas voir la modification effectué dans l'UI.

Franchement dans ce cas précis c'est peu courant, mais il s'agit de chose qui peuvent très bien arriver...

a++

[_Xavier_]

Donc le mot clef static n'a rien à voir là dedans


Ces deux méthodes étant protected on ne peut pas les appeler directement. Et sauf erreur on ne peut exécuter la tâche qu'une seule fois

Le theard A fait doInBackground : il modifie maObject
Le thread B fait onPostExecute : il lit maObject

Le fait d'avoir des méthodes protected éloigne le risque d'incohérence ?

Tu fais quoi de la variable partagée ?

Si tu n'utilises pas volatile tu n'est pas sûr du comportement. Donc tu pourrais ne pas voir la modification effectué dans l'UI.

Dans ce cas c'est pas thread-safe, d'où ma première intervention que l'auteur du thread ne semble pas apprécier.