<T>Future<T>

Bonjour
J'ai 1 question sur cette interface.

public class A{

private ExecutorService es=new Executors.newFixedThreadPool(3);
private List<Future<Integer>> fut=new CopyOnWriteArrayList<Future<Integer>>();
.........
public void m(){
fut.add((es.submit(new B()));
Integer i=fut.get(i).get();
}

}

J'aimerais savoir si le programme sera bloqué à la ligne "Integer i=fut.get(i).get();" ,si la methode B n'envoie jamais une réponse.

Merci par avance

Bonjour,

Sur le même sujet, que signifie exactement <T> Future<T> ? Si la fonction renvoie un Future<T>, pourquoi ajoute t'on <T> a la signature ?

Merci d'avance

AlexisLesGrosBras a écrit:Bonjour,

Sur le même sujet, que signifie exactement <T> Future<T> ? Si la fonction renvoie un Future<T>, pourquoi ajoute t'on <T> a la signature ?

Merci d'avance

Ici, T est générique. C'est n type non définit. Le Futur<T> est typé et rend une valeur (que l'on récupèrera) de type <T> lorsque celle-ci sera disponible.

Est-ce plus clair?

Heros a écrit:Bonjour
J'ai 1 question sur cette interface.

public class A{

private ExecutorService es=new Executors.newFixedThreadPool(3);
private List<Future<Integer>> fut=new CopyOnWriteArrayList<Future<Integer>>();
.........
public void m(){
fut.add((es.submit(new B()));
Integer i=fut.get(i).get();
}

}

J'aimerais savoir si le programme sera bloqué à la ligne "Integer i=fut.get(i).get();" ,si la methode B n'envoie jamais une réponse.

Merci par avance

Bonjour,

Votre question est mal libellée mais je pense en avoir compris le sens. N'hésitez pas si ce n'est pas le cas.

La ligne que vous citez est en effet bloquante tant que le get sur le future n'a pas rendu de valeur. ici, je vois mal ce que
vous voulez dire avec le second "get" qui suit (d'où mon doute sur la question) mais plusieurs choses peuvent empêcher
le get de s'exécuter, comme, par exemple:

1. le calcul est en cours et la valeur n'est pas encore connue (i.e. déposée via un "put")
   
2. l'ajout de la tâche dans le executor est bloquée car il n'y a pas de thread disponible (i.e. le calcul n'a pas encore commencé).
   

En tout état de cause, cela permet de récupérer une valeur calculée par une autre thread une fois que cette
dernière sera connue. c'est bien pratique dans certaines situation lorsque l'on peut avoir une référence
sur cette valeur en devenir dans un programme concurrent (ce n'est pas toujours le cas, par exemple, on ne
sait pas forcément qui recevra le résultat d'un calcul).

Est-ce plus clair?

Admin a écrit:

Heros a écrit:Bonjour
J'ai 1 question sur cette interface.

public class A{

private ExecutorService es=new Executors.newFixedThreadPool(3);
private List<Future<Integer>> fut=new CopyOnWriteArrayList<Future<Integer>>();
.........
public void m(){
fut.add((es.submit(new B()));
Integer i=fut.get(i).get();
}

}

J'aimerais savoir si le programme sera bloqué à la ligne "Integer i=fut.get(i).get();" ,si la methode B n'envoie jamais une réponse.

Merci par avance

Bonjour,

Votre question est mal libellée mais je pense en avoir compris le sens. N'hésitez pas si ce n'est pas le cas.

La ligne que vous citez est en effet bloquante tant que le get sur le future n'a pas rendu de valeur. ici, je vois mal ce que
vous voulez dire avec le second "get" qui suit (d'où mon doute sur la question) mais plusieurs choses peuvent empêcher
le get de s'exécuter, comme, par exemple:

1. le calcul est en cours et la valeur n'est pas encore connue (i.e. déposée via un "put")
   
2. l'ajout de la tâche dans le executor est bloquée car il n'y a pas de thread disponible (i.e. le calcul n'a pas encore commencé).
   

En tout état de cause, cela permet de récupérer une valeur calculée par une autre thread une fois que cette
dernière sera connue. c'est bien pratique dans certaines situation lorsque l'on peut avoir une référence
sur cette valeur en devenir dans un programme concurrent (ce n'est pas toujours le cas, par exemple, on ne
sait pas forcément qui recevra le résultat d'un calcul).

Est-ce plus clair?

Bonjour monsieur,
Merci de votre réponse, j'ai compris.

Pour les get(),je stocke le résultat dans la liste fut de type Future<Integer>, quand je récupère le résultat de la liste fut,
je fais fut.get(i),i est l'indice.
Le 2eme get() sert à récupérer la valeur associée, ici c'est une valeur de type Integer que j'attends comme résultat.
Est-ce que c'est comme cela qu'on reçoit les résultats?

Admin a écrit:

AlexisLesGrosBras a écrit:Bonjour,

Sur le même sujet, que signifie exactement <T> Future<T> ? Si la fonction renvoie un Future<T>, pourquoi ajoute t'on <T> a la signature ?

Merci d'avance

Ici, T est générique. C'est n type non définit. Le Futur<T> est typé et rend une valeur (que l'on récupèrera) de type <T> lorsque celle-ci sera disponible.

Est-ce plus clair?

Si j'ai bien compris vous parlez là de <T> Future<T>. Je comprends bien que c'est le type qui sera contenu dans le Future. Mais ce qui m'intrigue c'est le premier: <T> Future<T>. On récupère une valeur de type Future<T>, pourquoi ajoute-t-on <T> avant dans le type de retour. Si une methode "yolo" retourne une ArrayList d'Integer par exemple, la signature de la methode ne sera pas " <Integer> ArrayList<Integer> yolo() ". Si ?

Future est une interface générique paramétrée par le type T... et en effet, le T avant n'existe pas. Par contre, cette interface définit deux méthodes: get, qui red un T et put qui prend un T en paramètre.

Je vous recommande de lire le fantastic manual concernant les "future".