Discussion :

[Thierry5]

Bonjour,

J'ai un programme qui doit rechercher des chaines de caractères dans un unique fichier. Ce programme lance un thread pour chaque chaine différente à rechercher dans mon unique fichier.
Jusqu'à présent, chaque thread ouvre le fichier et parcourt les lignes à la recherche de sa chaîne de caractère. Du coup, forcément, ce n'est pas très efficace. Il y a certainement plus rapide.

Donc, maintenant, je veux optimiser ces recherches. J'ai donc créé un singleton qui lit le fichier et le mets dans un buffer. Jusque là tout va bien. Maintenant, j'ai besoin que chaque thread puisse parcourir ce buffer de manière indépendante pour faire sa propre recherche. Et là, c'est le drame !
Si j'utilise les méthodes habituelles de parcours d'un buffer, le multithreading fait que tout le monde s'emmêle les pinceaux. Pas mieux avec les regex.

Existe t-il une classe permettant de parcourir un buffer sans que le pointeur de positionnement du buffer soit lié à la classe du buffer ?
Je voudrais aussi éviter de copier mon buffer dans chaque thread.

Merci pour votre aide.

[Nudger]

Bonjour,

le multithreading fait que tout le monde s'emmêle les pinceaux

Pour ça il existe le mot clé synchronized.
Placé au bon endroit, il n'y aura plus "d'emmêlage" de pinceaux.
Mais ça peut générer des latences car les threads ne peuvent pas tous passer en même temps dans le code synchronisé. Donc à utiliser de manière très localisée et avec parcimonie.

[le y@m's]

Un peu de lecture sur les Threads et la synchronisation

• Thread et Communication en Java
• Java et la synchronisation
• Programmation des Threads en Java

[tchize_]

Pourquoi tu ne testre par toutes les chaines en même temps dans un seul thread? Ce qui ralentit l'application dans ce cas ci, ce n'est pas temps le CPU mais les IO. Or multithreader ne sert qu'à optimiser l'utilisation CPU, ce qui n'est déjà pas ton point de ralentissement ici. Tu ne va rien y gagner.

Par plutot sur cette logique:

Code :

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

1
2
3
tant que une ligne est lue du fichier
  pour chaque chaine à chercher
    si ligne contient chaine à rechercher alors action

Maintenant ce que tu peux éventuellement faire c'est avoir un Thread 1 qui lit ligne par ligne le fichier et met les lignes dans une BlockingDeque et avoir un thread2 qui, pour chaque ligne lue, la scanne à la rechreche de pattern.

Au moins là tu aura le CPU qui tourne en parallèle avec les disques.

[Thierry5]

Merci pour vos réponses rapides !

Concernant le multithreading, j'ai lu et relu des doc, j'ai fait des tas de tests, mais je n'ai pas trouvé la solution.
Et concernant le mot clé "synchronized", je ne veux pas l'utiliser dans ce contexte car cela signifierait que je perds tout le temps que je cherche à gagner : au contraire, je souhaite que chaque thread puisse effectuer sa recherche en parallèle des autres et non de manière séquentielle mais sur un même buffer partagé.
Dans les classes que j'ai trouvé, toutes les méthodes de parcours d'un buffer incluent le buffer ET le positionnement dans le parcours du buffer. Là est mon problème. Car chaque thread doit pouvoir parcourir le buffer en même temps que les autres, mais son positionnement dans le buffer doit lui être propre.

Bon, je vais essayer d'illustrer.

Ci-dessous ma fonction de recherche où tout s'embrouille :

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
 
    private String ligneTrouvee = new String();
    private Pattern linePattern = Pattern.compile(".*\r?\n");
    private String ligneRecherchee;
 
    /**
     * Recherche la directive dans le buffer passé en paramètre.
     * 
     * @param cb CharBuffer contenant le fichier de log à parcourir pour trouver la directive
     * @param direct Directive à retrouver dans le buffer
     * @return boolean Retourne CodeRetour.SEARCH_FOUND si la directive a été trouvée, CodeRetour.SEARCH_NOTFOUND dans le cas contraire 
     */
    private boolean grep(CharBuffer cb, String direct) {
    	boolean bTrouvee = CodeRetour.SEARCH_NOTFOUND;
	StringBuffer directive = new StringBuffer(direct);
	ligneRecherchee = new String();
	Matcher lm = linePattern.matcher(cb);	// Line matcher
	int lines = 0;
	while (lm.find() && !bTrouvee) {
		lines++;
		ligneRecherchee=lm.group(); // The current line
 
		if (ligneRecherchee.indexOf(directive.toString())>0) {
	    		System.out.println("grep	Thread ID : "+Thread.currentThread().getId()+"	Directive trouvée : " + directive);
	    		ligneTrouvee=ligneRecherchee;
		    	bTrouvee = CodeRetour.SEARCH_FOUND;
		}
		if (lm.end() == cb.limit())
		    	break;
	}
	return bTrouvee;
    }

Mon CharBuffer est commun à tous les threads.
J'utilise les RegEx pour identifier les lignes dans mon Buffer, puis je recherche ma "directive" (différente pour chaque Thread) dans la ligne.
Et là, de manière générale, mes résultats sont incohérents : avec plusieurs threads qui font des recherches différentes, je vais me retrouver avec la même ligne en résultat ou avec une ligne qui n'est pas la bonne...

[Thierry5]

Pourquoi tu ne testre par toutes les chaines en même temps dans un seul thread?

Malheureusement, je ne maîtrise pas toute la chaîne : je n'ai pas la main sur le process principal qui va générer autant de thread que de chaînes à rechercher...

[tchize_]

charbuffer n'est pas threadsafe et c'est tout.
Tu ne veux pas de synchronized -> un charbuffer par thread. Et tu va multiplier d'autant tes IOs, ce qui va écrouler l'application.

Solution -> oublier l'idée des thread et tout regrouper.

Je rajoute qu'il ya a quelques erreurs de perfs dans ton code à corriger avant même d'envisager la parallélisation pour "optimiser". Il vaut mieux commencer par faire un code performant avant d'imaginer que le multithread est une solution magiques aux performances.

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
    private boolean grep(CharBuffer cb, String direct) {
    	boolean bTrouvee = CodeRetour.SEARCH_NOTFOUND;
	StringBuffer directive = new StringBuffer(direct); // pourquoi en faire un StringBuffer???
	ligneRecherchee = new String(); //String vide inutile
	Matcher lm = linePattern.matcher(cb);	// Si le but est de découper en lignes, un BufferedReader sera plus performant et simple à utiliser!
	int lines = 0;
	while (lm.find() && !bTrouvee) {
		lines++;
		ligneRecherchee=lm.group(); // The current line
 
		// pourquoi mélanger une recherche par regexp (linePattern et un indexOf??)
                // un toString() dans une boucle, totalement inutile, fait le toString une seule fois avant la boucle.
		if (ligneRecherchee.indexOf(directive.toString())>0) {
	    		System.out.println("grep	Thread ID : "+Thread.currentThread().getId()+"	Directive trouvée : " + directive);
	    		ligneTrouvee=ligneRecherchee;
		    	bTrouvee = CodeRetour.SEARCH_FOUND;
		}
		if (lm.end() == cb.limit()) //test inutile, find renverra false dans le while!
		    	break;
	}
	return bTrouvee;
    }

[bulbo]

Bonjour,

Déjà je ne vois pas en quoi des lectures multiples d'une donnée qui ne change pas puissent poser des problème de synchronisation.

Il suffit que chaque thread ait son propre index de positionnement en local et on n'en parle plus.

Mais dans l'absolu je suis plus pour la solution de tchize à savoir un seul thread mais une détection de toutes les chaînes à la fois.. après si les chaînes à détecter sont toujours toujours les même, pourquoi ne pas imaginer même un automate pour cette détection ce serait bien plus efficace que X threads.

Après il faut savoir si l'important ce sont les performances ou si c'est d'avoir plusieurs threads .. les deux n'étant pas forcément synonymes.

Bulbo

[Thierry5]

charbuffer n'est pas threadsafe et c'est tout.
Tu ne veux pas de synchronized -> un charbuffer par thread. Et tu va multiplier d'autant tes IOs, ce qui va écrouler l'application.

Si le charbuffer n'est pas threadsafe (en fait c'est ce que j'aurais dû déduire de mes problèmes), ceci explique grandement mes problèmes ! Merci pour tous ces éléments et pistes de correction. Je regarde tout ça.

Solution -> oublier l'idée des thread et tout regrouper.

Malheureusement, je n'ai pas le choix. Je développe une extension à une application qui n'appellera mon code qu'à travers des threads...

[Thierry5]

Il suffit que chaque thread ait son propre index de positionnement en local et on n'en parle plus.

Oui, c'est ça que je cherche : mais est-ce qu'il existe une classe particulière pour cela ?

Pour le reste, chaque thread à sa propre chaine de caractère à rechercher et je suis obligé d'utiliser des threads.

[bulbo]

Il ne faut pas rêver non plus

Mais si tu stockes tes fichiers dans un tableau de char par exemple, rien ne t'empêche d'écrire, de façon optimisée, une classe que tu initialises avec ledit tableau et qui va y rechercher une chaîne de caractère.

Tu crée X instances de cette classe avec le même tableau et une chaîne différente que tu lances dans X threads différent.. fin de l'histoire.

Et pas de synchronisation de nécessaire.

Après cette solution là ne fonctionne que sur des fichiers pouvant tenir complètement en mémoire. Si tu dois faire cette recherche sur des trucs de l'ordre du giga ou plus .. tu vas avoir des soucis de mémoire rapidement.

Ensuite sans en connaître plus sur le style de recherche (multi-lignes ou pas etc) ou les conditions d'arrêts des dites recherches, dur de t'aiguiller plus avant.

Bulbo

[Thierry5]

Il ne faut pas rêver non plus

Dommage !

Mais si tu stockes tes fichiers dans un tableau de char par exemple, rien ne t'empêche d'écrire, de façon optimisée, une classe que tu initialises avec ledit tableau et qui va y rechercher une chaîne de caractère.

Tu crée X instances de cette classe avec le même tableau et une chaîne différente que tu lances dans X threads différent.. fin de l'histoire.

Ben j'aurai voulu éviter d'avoir mon fichier en mémoire X fois...

Et pas de synchronisation de nécessaire.

Effectivement, j'avais constaté que ça ne répondait pas à mon problème.

Après cette solution là ne fonctionne que sur des fichiers pouvant tenir complètement en mémoire. Si tu dois faire cette recherche sur des trucs de l'ordre du giga ou plus .. tu vas avoir des soucis de mémoire rapidement.

Ensuite sans en connaître plus sur le style de recherche (multi-lignes ou pas etc) ou les conditions d'arrêts des dites recherches, dur de t'aiguiller plus avant.

Bulbo

Il s'agit d'un fichier qui fait entre 150 et 200 ko et chaque thread ne recherche, dans ce fichier, que LA ligne contenant ce que j'ai appelé "directive".

Bon je fais des essais avec tous ces éléments.

[tchize_]

Malheureusement, je n'ai pas le choix. Je développe une extension à une application qui n'appellera mon code qu'à travers des threads...

Visiblement, tu arrive à réunir ces threads pour qu'ils utilisent tous le même charbuffer. Ou est donc le problème de les réunir différement: chaque thread poste son critère de recherche dans une liste (synchronizée). Quand tous les thread on posté dans la liste, un thread principal démarre, scanne le fichier pour tous ces critères et donnes les réponses aux threads appelant. Ceuxi-ci, une fois la réponse recue, renvoient à leur appelant.

[bulbo]

Attention tu n'auras pas ton fichier X fois en mémoire avec la solution que je t'avais proposée.

Tu auras X instances ayant une référence sur l'unique tableau de char correspondant aux données de ton fichier nuance.

Vu les contraintes exposées .. ça sent le TP sur le multi-threading si c'est le cas je précise de suite que ma solution ne va pas faire date si le but était d'avoir un producteur et de multiples consommateurs l'utilisant

Elle marche bien, mais by-pass la problématique en question complètement. Et s'il faut savoir si la chaîne est trouvée le plus vite possible, idem, car là on lira systématiquement tout le fichier.

Dans un environnement réel, 200ko de fichier, on ne se pose même pas la question, dans un environnement TP multi-thread .. là c'est une autre histoire.

J'ai bien des idées, mais j'ai déjà tous les diplômes dont j'ai besoin

Bulbo

[Thierry5]

Attention tu n'auras pas ton fichier X fois en mémoire avec la solution que je t'avais proposée.

Tu auras X instances ayant une référence sur l'unique tableau de char correspondant aux données de ton fichier nuance.

Oups, j'ai lu un peu vite !!

Vu les contraintes exposées .. ça sent le TP sur le multi-threading si c'est le cas je précise de suite que ma solution ne va pas faire date si le but était d'avoir un producteur et de multiples consommateurs l'utilisant

Elle marche bien, mais by-pass la problématique en question complètement. Et s'il faut savoir si la chaîne est trouvée le plus vite possible, idem, car là on lira systématiquement tout le fichier.

Dans un environnement réel, 200ko de fichier, on ne se pose même pas la question, dans un environnement TP multi-thread .. là c'est une autre histoire.

Non, il ne s'agit pas d'un TP mais d'un cas bien réel, même si cela ressemble beaucoup à un cas d'école avec des Design Patterns et tout et tout. Je n'ai exposé ici que la partie qui me posait problème !

[thelvin]

Personnellement je ne vois pas bien pourquoi il a été question de CharBuffer et pourquoi on parle de partage d'index et de position.
C'est une recherche à faire. Ça peut se faire dans une simple String. Il suffisait de charger dans une String. String a des méthodes qui servent à ça et qui sont nettement mieux pensées que CharBuffer. Il est où le problème ?

[Thierry5]

Le CharBuffer est un faux problème. La problématique est surtout de retrouver, dans un buffer chargé à partir du contenu d'un fichier, LA ligne qui contient la chaine de caractère que j'appelle "directive". Et ceci dans un contexte multithread puisque chaque recherche s'effectue dans un thread différent.

Si avec un String on peut tout faire, je suis aussi intéressé !

[tchize_]

l'erreur est de croire qu'avec charbuffer le fichier est chargé. CharBuffer n'est qu'une interface IO qui lit le fichier au fur et à mesure des appels à l'interface CharSequence. Il n'est donc pas en mémoire et il n'est donc pas question d'index.

Si tu veux tout charger en mémoire, tu met tout dans une String et tout le monde travail sur la String. String étant immutable, il est threadsafe.

[Thierry5]

Merci à tous pour vos réponses. J'obtiens finalement quelque chose de beaucoup plus simple et qui fonctionne !!

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
 
   private final static String sautDeLigne = System.getProperty("line.separator");
 
   private boolean grep(String buffer, String directive) {
    	boolean bTrouvee = CodeRetour.SEARCH_NOTFOUND;
    	String ligneTrouvee;
    	int pos, debut, fin = 0;
 
	if ((pos = buffer.indexOf(directive))>0) {
		debut = buffer.lastIndexOf(sautDeLigne, pos)+2; //Bon, il faudrait plutôt compter le nombre de caractère de saut de ligne...
		fin = buffer.indexOf(sautDeLigne, pos);
		ligneTrouvee=buffer.substring(debut, fin);
	    	bTrouvee = CodeRetour.SEARCH_FOUND;
	}
 
	return bTrouvee;    	
    }

Voilà, ceci fonctionne bien, mais ne résoud pas tous mes problèmes. Cependant je considère ce point comme résolu et j'ouvre une autre discussion.