Discussion :

[FabaCoeur]

Bonjour,

Dans mon projet actuel, j'ai une application fenêtrée qui utilise plusieurs fenêtres. Les coordonnées des composants qui composent chacune des fenêtres est stockés dans un fichier texte (un fichier par fenêtre).

J'ai codé une classe qui contient une méthode qui charge un fichier de coordonnée et l'enregistre dans une table de hachage. Une fois dans la table, les fenêtre peuvent lire les coordonnées (avec une rapidité sans égal).

Actuellement, chaque fichier est chargé au moment de la création de la fenêtre. Les fichiers ne sont pas gros, mais on pourrait prévoir qu'a force de rajouter des coordonnées, cela occasionne un petit temps de chargement à la création de chaque fenêtre, effet non désiré.

C'est pour cela que je voudrais créer un second thread sur ma fenêtre principale, qui chargerai tous les fichiers de coordonnées dans la table de hachage (en prévision des futures création de fenêtre). Ainsi le second thread profiterai du temps laissé par l'utilisateur (une courte lecture par exemple) pour une activité utile !

Que pensez-vous de cette idée, est-elle cohérente ?
Je voudrais aussi savoir, comment est répartie l'activité entre les thread ? Si dans mon thread principal l'utilisateur fait une action qui demande de la ressource, le second thread qui va travailler en tache de fond va-t-il ralentir le premier ? Peut-on définir quel thread doit travailler en priorité ?

Merci de m'éclairer un peu sur la question

[FabaCoeur]

Je viens de commencer à mettre le procédé en place, cela semble marcher (mais dur à vérifier étant donné que l'on ne voie pas toujours ce qui se passe en temps et en heure).
Pour ce qui est de la priorité, j'ai trouvé la solution avec setPriority().

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class Position {
 
 
	// Table de coordonnée
	private static HashMap<String, Rectangle> hm = null;
 
 
	/* ... */
 
 
	// Pré-charge les fichiers désirés dans un nouveau thread
	public static void preChargement(final String[] fichiers) {
 
		// Création du thread
		Thread loader = new Thread() {
 
			if(hm == null)
				hm = new HashMap<String, Rectangle>();
 
			public void run() {
 
				for(int i=0; i < fichiers.length; i++)
					chargerFichier(fichiers[i]);
 
				return; // Fin du thread
			}
		};
 
		loader.setDaemon(true);
		loader.setPriority( Thread.MIN_PRIORITY );
		loader.start();
	}
 
}

Le soucis: Il semblerai que HashMap ne soit pas une classe synchronisée. Toutes les recherches que j'ai fait m'ont amené à utiliser Collections.synchronizedMap, le problème c'est que cela retourne une classe Map qui est une vue de la table, mais il n'est pas possible d'ajouter dans une vue, je me trompe ?

[eclesia]

(avec une rapidité sans égal)

*taquine* qu'est ce qui te rend aussi sur de toi?

Le soucis: Il semblerai que HashMap ne soit pas une classe synchronisée.

tu peux utiliser un ConcurrentHashMap
cf : http://java.sun.com/j2se/1.5.0/docs/...ntHashMap.html

Pour ce qui est de la priorité, j'ai trouvé la solution avec setPriority().

le resultat et l'effet sont aléatoire, ca depend de la plateforme, de la JVM ...etc... donc ne l'utilise pas comme une sacro-sainte vérité.

Je voudrais aussi savoir, comment est répartie l'activité entre les thread ? Si dans mon thread principal l'utilisateur fait une action qui demande de la ressource, le second thread qui va travailler en tache de fond va-t-il ralentir le premier ? Peut-on définir quel thread doit travailler en priorité ?

Il n'y a pas vraiment de facon de savoir qui est prioritaire. C'est en tout cas obligé qu'un thread en tache de fond ralentisse les autres threads. c'est le systeme qui va decider du temps alloué a chaque thread.

Apres c'est a toi de bien coordonner l'action des threads, en utilisant : "synchronized", thread.notify() ou notifyAll(), sleep()...etc...

[FabaCoeur]

Tout d'abord merci pour tes réponses.

*taquine* qu'est ce qui te rend aussi sur de toi?

Parce que la Hashtable c'est la puissance même ^^

tu peux utiliser un ConcurrentHashMap
cf : http://java.sun.com/j2se/1.5.0/docs/...ntHashMap.html

Il suffit que je change HashMap en ConcurrentHashMap et le tour est joué ?
Ca semble trop facile Oo

Sinon je viens de trouver une solution, mais je ne sais pas si elle est bonne:
Je met la méthode chargerFichier en synchronized, en effet il n'y a que cette méthode qui ajoute des entrées à la HashMap. Donc si la méthode est synchronisée, il n'y aura pas deux threads qui vont ajouter des choses dedans en même temps.
Mais est ce que cela est un problème si d'un coté le thread ajoute, et pendant ce temps un autre lit le contenu de la table ?

le resultat et l'effet sont aléatoire, ca depend de la plateforme, de la JVM ...etc... donc ne l'utilise pas comme une sacro-sainte vérité.

Oui c'est certain que la plateforme aura son mot à jouer, mais en mettant la priorité au plus bas on peut supposer (ou plutot espérer) que le thread passera après le principal dans un moment critique.

[eclesia]

ConcurrentHashMap ca porte son bien son nom :

A hash table supporting full concurrency of retrievals and adjustable expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.

c'est presque trop simple comme tu dis

[let_me_in]

pour causer l'arrete temporaire du thread afin que d'autre thread puissent s'executer, il y a la methode yield :

public static void yield()

Causes the currently executing thread object to temporarily pause and allow other threads to execute.

pour ce qui est de l'implementation, debrouille toi !

[FabaCoeur]

Ha ouais en effet en fait c'est pas bien compliqué !
Dans la doc j'ai vu que en revanche dans une ConcurrentHashMap les valeurs ne peuvent pas être null.

pour causer l'arrete temporaire du thread afin que d'autre thread puissent s'executer, il y a la methode yield

En fait dans mon cas d'utilisation, le thread sert une seule fois au début pour charger les fichiers. Après, il ne servira plus jamais, comment le "tuer" ?

[eclesia]

une fois que le thread arrive a la fin de la methode run(), il est terminé. si tu n'as aucune reference vers ce thread il va etre detruit.

[adiGuba]

le problème c'est que cela retourne une classe Map qui est une vue de la table, mais il n'est pas possible d'ajouter dans une vue, je me trompe ?

Je ne comprend pas ce que tu veux dire par "une vue" !?
Collections.synchronizedMap() te retourne une Map synchronizé, qui s'utilise par la suite comme toutes les autres Map (sauf pour les parcours via iterateur qu'il faut synchronizé).

En fait dans mon cas d'utilisation, le thread sert une seule fois au début pour charger les fichiers. Après, il ne servira plus jamais, comment le "tuer" ?

Un thread "meurt" dès que sa méthode run() est finie...


a++

[FabaCoeur]

Je ne comprend pas ce que tu veux dire par "une vue" !?
Collections.synchronizedMap() te retourne une Map synchronizé, qui s'utilise par la suite comme toutes les autres Map (sauf pour les parcours via iterateur qu'il faut synchronizé).

En fait je pensais que l'on ne pouvait pas insérer dans la Map, enfin que l'ajout ne serai pas répercuté sur la HashMap en fait, je pensais avoir lu ça dans mon livre mais comme la méthode put() de Map est bien définie dans la JavaDoc je pense qu'en fait je voyais des contraintes qui n'existaient pas ^^'

Un thread "meurt" dès que sa méthode run() est finie...

une fois que le thread arrive a la fin de la methode run(), il est terminé. si tu n'as aucune reference vers ce thread il va etre detruit.

C'est bien ce que je pensais, donc pas de soucis.
On peut donc interrompre un thread avec un simple return;.


Merci à tous pour votre aide
C'était vraiment pas dur en fait ^^

[dingoth]

En fait je pensais que l'on ne pouvait pas insérer dans la Map, enfin que l'ajout ne serai pas répercuté sur la HashMap en fait, je pensais avoir lu ça dans mon livre mais comme la méthode put() de Map est bien définie dans la JavaDoc je pense qu'en fait je voyais des contraintes qui n'existaient pas ^^'

tu devais confondre avec la méthode Collections.unmodifiableMap(...)