[Thread] écriture d'un fichier de façon asynchrone

Version imprimable

06/08/2006, 04h50
Sergejack

[Thread] écriture d'un fichier de façon asynchrone

J'aimerais pouvoir à partir de mes programmes lancer l'écriture de fichiers pour lesquels je donnerais les données à écrire au fure et à mesure.
J'aimerais avoir une solution assez générique (dans le choix du type de fichier byte/string).

J'aimerais une solution propre c'est pourquoi, je ne vais pas expliquez mes propres tentatives de réponse à ce problème, mais sachez qu'il y en a eu et que, non, je ne suis pas paresseux; je suis seulement conscient de peut-être faire mal, voire d'être incapable de faire bien par manque de certainnes connaissances (c'est de l'ordre de la remise en question donc).

Si, quand même, pour clarifier ma requête ce que j'ai fait peut-être utile, voilà :
Une file de valeurs accédées par des méthode synchronizées.
Mon thread principale met des valeur dans cette file.
Un thread secondaire récupère les valeurs de la file et les inscrit sur disque.
Que cela ne vous serve qu'à cerner le problème surtout, je ne veux absolument pas borner la solution.

Merci :)

PS : C'est bien du code que je demande (et (re ?)découvrir des mécanismes, des classes,...).
06/08/2006, 14h35
spekal

Tout d'abord, dans le domaine des accés concurents, il n'y a pas de solution qui passe partout.

Mais la solution du synchronized passe dans 99,99% des cas. C'est synchronized (toto) { fout.write(mesBytes);}. C'est tout.

A te lire, j'ai l'impression que tu l'as déjà essayée... et que tu n'es pas arrivé à la faire marcher. Je pense que c'est plus parce que les problèmes d'accés concurrents sont facilement prise de tête, et que c'est plutôt au niveau de la déprise de tête qu'il faut avancer. Or, dans ce domaine tu ne nous en dit pas beaucoup.

Pourrais-tu nous présenter les choses dans un style pseudo-code ?

... et je t'assure que, s'il s'agit juste de coordonner les écritures vers un fichier, la solution que je te donne plus haut suffit largement :D

Les erreurs habituelles sont :
- est-ce que toto est bien le même pour tous les threads ?
- est-ce que fout est le même aussi ?
- est-ce que tous les threads attendent bien que le fichier soit ouvert avant de commencer à écrire dedans ?
- pareil coté fermeture, avec la subtilité du flush.
- (la solution pour l'ouverture et la fermeture oblige en général à synchronizer aussi ces actions, sur toto).
- est-ce que le contenu de mesBytes représente bien l'ensemble de ce que je veux écrire ? Est-ce que ce buffer n'est pas lui même utilisé par plusieurs threads ? (il FAUT que ce buffer soit différent pour tous les threads).

... Et tout ce que tu peux imaginer qu'on n'imagine pas.

Alors aprés avoir lu ta question,
Je me suis dit qu'une des seules façon d'être générique est de proposer un OutputStream qui serait asynchrone.

J'ai donc ecrit à titre d'exemple une version qui mérite certaines amélioration:
- Etant Asynchrone, les IOException sont actuellement perdues, il faut mettre en place un mécanisme (à partir de UncaughtExceptionHandler) permettant de remonter à un appel ulterieur une IOException levée.

Remarque:
- Autant les méthodes write(...) sont asynchrone, autant la méthode close() attends la fin de toutes les écritures avant de rendre la main
- Les méthodes write(...) n'ont pas besoin d'etre synchronisées, l'ExecutorService synchronize ce qui est nécessaire dans un environnement multi-thread
- Il est vivement conseillé d'englober l'output stream asynchrone par un output stream bufferisé afin de gerer l'ecriture asynchrone par paquets et non par byte.

Bon voici l'exemple:

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
 
import java.io.BufferedOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
 
/**
 * Handle an Asynchronous OutputStream that allow to differ the writing process.
 * This is an example purpose, and with this implementations IOException are uncaughted.. 
 * Maybe we should use an UncaughtExceptionHandler to complete this design.
 *
 * All write() methods are ASynchronous but the close() method wait until all are "writted" to the destination outputstream
 *
 * Exemple to use:
 *
 * BufferedOutputStream bos = new BufferedOutputStream( new ASyncOutputStream( new FileOutputStream( "c:\\Test.txt" ) ) );
 * bos.write( "A first line".getBytes() );
 * bos.write( "A second one".getBytes() );
 * bos.write( "the last one".getBytes() );
 * bose.close();
 *
 * @author André Sébastien
 */
public class ASyncOutputStream extends OutputStream
{
    private OutputStream    out = null;
    private ExecutorService es = null;
 
    /** Creates a new instance of AsyncOutputStream */
    public ASyncOutputStream(OutputStream o)
    {
        this.out = o;
        this.es = Executors.newSingleThreadExecutor();
    }
 
    /**
     * Writes the specified byte to this output stream. The general 
     * contract for <code>write</code> is that one byte is written 
     * to the output stream. The byte to be written is the eight 
     * low-order bits of the argument <code>b</code>. The 24 
     * high-order bits of <code>b</code> are ignored.
     * <p>
     * Subclasses of <code>OutputStream</code> must provide an 
     * implementation for this method. 
     * 
     * 
     * @param b   the <code>byte</code>.
     * @exception IOException  if an I/O error occurs. In particular, 
     *             an <code>IOException</code> may be thrown if the 
     *             output stream has been closed.
     */
    public void write(final int b) throws IOException {
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.write(b);
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * Writes <code>len</code> bytes from the specified byte array 
     * starting at offset <code>off</code> to this output stream. 
     * The general contract for <code>write(b, off, len)</code> is that 
     * some of the bytes in the array <code>b</code> are written to the 
     * output stream in order; element <code>b[off]</code> is the first 
     * byte written and <code>b[off+len-1]</code> is the last byte written 
     * by this operation.
     * <p>
     * The <code>write</code> method of <code>OutputStream</code> calls 
     * the write method of one argument on each of the bytes to be 
     * written out. Subclasses are encouraged to override this method and 
     * provide a more efficient implementation. 
     * <p>
     * If <code>b</code> is <code>null</code>, a 
     * <code>NullPointerException</code> is thrown.
     * <p>
     * If <code>off</code> is negative, or <code>len</code> is negative, or 
     * <code>off+len</code> is greater than the length of the array 
     * <code>b</code>, then an <tt>IndexOutOfBoundsException</tt> is thrown.
     * 
     * 
     * @param b     the data.
     * @param off   the start offset in the data.
     * @param len   the number of bytes to write.
     * @exception IOException  if an I/O error occurs. In particular, 
     *             an <code>IOException</code> is thrown if the output 
     *             stream is closed.
     */
    public void write(final byte[] b, final int off, final int len) throws IOException {
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.write(b,off,len);
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * Closes this output stream and releases any system resources 
     * associated with this stream. The general contract of <code>close</code> 
     * is that it closes the output stream. A closed stream cannot perform 
     * output operations and cannot be reopened.
     * <p>
     * The <code>close</code> method of <code>OutputStream</code> does nothing.
     * 
     * 
     * @exception IOException  if an I/O error occurs.
     */
    public void close() throws IOException {
        super.close();
 
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.close();
                    ASyncOutputStream.this.es.shutdown();
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
 
        // Execute and wait the sucess
        Future future = this.es.submit(doRun);
        try
        {
            future.get();
        }
        catch(Exception e){ e.printStackTrace(); }
    }
 
    /**
     * Flushes this output stream and forces any buffered output bytes 
     * to be written out. The general contract of <code>flush</code> is 
     * that calling it is an indication that, if any bytes previously 
     * written have been buffered by the implementation of the output 
     * stream, such bytes should immediately be written to their 
     * intended destination.
     * <p>
     * If the intended destination of this stream is an abstraction provided by
     * the underlying operating system, for example a file, then flushing the
     * stream guarantees only that bytes previously written to the stream are
     * passed to the operating system for writing; it does not guarantee that
     * they are actually written to a physical device such as a disk drive.
     * <p>
     * The <code>flush</code> method of <code>OutputStream</code> does nothing.
     * 
     * 
     * @exception IOException  if an I/O error occurs.
     */
    public void flush() throws IOException {
        super.flush();
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.flush();
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
       try
       {
           BufferedOutputStream bos = new BufferedOutputStream( new ASyncOutputStream( new FileOutputStream( "c:\\Test.txt" ) ) );
           bos.write( "A first line".getBytes() );
           bos.write( "A second one".getBytes() );
           bos.write( "the last one".getBytes() );
           bos.close();
       }
       catch(Exception e){ e.printStackTrace(); }
 
    }
}

Citation:

Envoyé par divxdede

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
 
import java.io.BufferedOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
 
/**
 * Handle an Asynchronous OutputStream that allow to differ the writing process.
 * This is an example purpose, and with this implementations IOException are uncaughted.. 
 * Maybe we should use an UncaughtExceptionHandler to complete this design.
 *
 * All write() methods are ASynchronous but the close() method wait until all are "writted" to the destination outputstream
 *
 * Exemple to use:
 *
 * BufferedOutputStream bos = new BufferedOutputStream( new ASyncOutputStream( new FileOutputStream( "c:\\Test.txt" ) ) );
 * bos.write( "A first line".getBytes() );
 * bos.write( "A second one".getBytes() );
 * bos.write( "the last one".getBytes() );
 * bose.close();
 *
 * @author André Sébastien
 */
public class ASyncOutputStream extends OutputStream
{
    private OutputStream    out = null;
    private ExecutorService es = null;
 
    /** Creates a new instance of AsyncOutputStream */
    public ASyncOutputStream(OutputStream o)
    {
        this.out = o;
        this.es = Executors.newSingleThreadExecutor();
    }
 
    /**
     * Writes the specified byte to this output stream. The general 
     * contract for <code>write</code> is that one byte is written 
     * to the output stream. The byte to be written is the eight 
     * low-order bits of the argument <code>b</code>. The 24 
     * high-order bits of <code>b</code> are ignored.
     * <p>
     * Subclasses of <code>OutputStream</code> must provide an 
     * implementation for this method. 
     * 
     * 
     * @param b   the <code>byte</code>.
     * @exception IOException  if an I/O error occurs. In particular, 
     *             an <code>IOException</code> may be thrown if the 
     *             output stream has been closed.
     */
    public void write(final int b) throws IOException {
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.write(b);
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * Writes <code>len</code> bytes from the specified byte array 
     * starting at offset <code>off</code> to this output stream. 
     * The general contract for <code>write(b, off, len)</code> is that 
     * some of the bytes in the array <code>b</code> are written to the 
     * output stream in order; element <code>b[off]</code> is the first 
     * byte written and <code>b[off+len-1]</code> is the last byte written 
     * by this operation.
     * <p>
     * The <code>write</code> method of <code>OutputStream</code> calls 
     * the write method of one argument on each of the bytes to be 
     * written out. Subclasses are encouraged to override this method and 
     * provide a more efficient implementation. 
     * <p>
     * If <code>b</code> is <code>null</code>, a 
     * <code>NullPointerException</code> is thrown.
     * <p>
     * If <code>off</code> is negative, or <code>len</code> is negative, or 
     * <code>off+len</code> is greater than the length of the array 
     * <code>b</code>, then an <tt>IndexOutOfBoundsException</tt> is thrown.
     * 
     * 
     * @param b     the data.
     * @param off   the start offset in the data.
     * @param len   the number of bytes to write.
     * @exception IOException  if an I/O error occurs. In particular, 
     *             an <code>IOException</code> is thrown if the output 
     *             stream is closed.
     */
    public void write(final byte[] b, final int off, final int len) throws IOException {
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.write(b,off,len);
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * Closes this output stream and releases any system resources 
     * associated with this stream. The general contract of <code>close</code> 
     * is that it closes the output stream. A closed stream cannot perform 
     * output operations and cannot be reopened.
     * <p>
     * The <code>close</code> method of <code>OutputStream</code> does nothing.
     * 
     * 
     * @exception IOException  if an I/O error occurs.
     */
    public void close() throws IOException {
        super.close();
 
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.close();
                    ASyncOutputStream.this.es.shutdown();
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
 
        // Execute and wait the sucess
        Future future = this.es.submit(doRun);
        try
        {
            future.get();
        }
        catch(Exception e){ e.printStackTrace(); }
    }
 
    /**
     * Flushes this output stream and forces any buffered output bytes 
     * to be written out. The general contract of <code>flush</code> is 
     * that calling it is an indication that, if any bytes previously 
     * written have been buffered by the implementation of the output 
     * stream, such bytes should immediately be written to their 
     * intended destination.
     * <p>
     * If the intended destination of this stream is an abstraction provided by
     * the underlying operating system, for example a file, then flushing the
     * stream guarantees only that bytes previously written to the stream are
     * passed to the operating system for writing; it does not guarantee that
     * they are actually written to a physical device such as a disk drive.
     * <p>
     * The <code>flush</code> method of <code>OutputStream</code> does nothing.
     * 
     * 
     * @exception IOException  if an I/O error occurs.
     */
    public void flush() throws IOException {
        super.flush();
        Runnable doRun = new Runnable()
        {
            public void run() 
            {
                try
                {
                    ASyncOutputStream.this.out.flush();
                }
                catch(Exception e)
                { /* Maybe you should handle theses exceptions by a UncaughtExceptionHandler */ 
                  e.printStackTrace();
                }
            }
        };
        this.es.execute(doRun);
    }
 
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
       try
       {
           BufferedOutputStream bos = new BufferedOutputStream( new ASyncOutputStream( new FileOutputStream( "c:\\Test.txt" ) ) );
           bos.write( "A first line".getBytes() );
           bos.write( "A second one".getBytes() );
           bos.write( "the last one".getBytes() );
           bos.close();
       }
       catch(Exception e){ e.printStackTrace(); }
 
    }
}

Comment faire un UncaughtExceptionHandler puisqu'il y a ici ni instance de Thread encore moins de ThreadGroup (et utiliser celui par défaut, static à la classe Thread est un raccourcit qui ne répondrait pas à des besoins plus spécifiques).

PS: Ce mécanisme est-il vraiment plus intéressant qu'un autre où ne serait créer qu'un seul autre thread, un thread consomateur (puisqu'il lit pour écrire sur fichier)

07/08/2006, 07h52
divxdede

Pour gerer l'handler il faut passer un ThreadFactory a l'executors afin qu'il genere un Thread correctement configuré

L'executorService permet d'ignorer une partie de l'implementation du "pool" et met a disposition les Future.

Sinon aprés coups j'emet une reserve sur l'accés concurrent si ASyncOutputStream est enrobé par un BufferedOutpoutStream (je n'ai pas verifier que ce dernier etant thread-safe)
07/08/2006, 16h04
Sergejack

Ce mécanisme est-il vraiment plus intéressant qu'un autre où ne serait créer qu'un seul autre thread, un thread consomateur (puisqu'il lit pour écrire sur fichier)
07/08/2006, 16h27
divxdede

Citation:

Envoyé par Sergejack

Ce mécanisme est-il vraiment plus intéressant qu'un autre où ne serait créer qu'un seul autre thread, un thread consomateur (puisqu'il lit pour écrire sur fichier)

pas tellement mais c'est tellement plus simple :)

Executors à 2 avantages:
- Gerer l'execution de taches planifiés de facon "normé". Ensuite qu'il y ai 1 thread ou n threads c'est du ressors de l'implementation de L'ExecutorService. La gestion manuelle d'un thread peut revenir au même.

- Gére la communication avec le/les threads d'execution avec un objet "Future" permettant de savoir si une tache est en cours/terminé/toujours en attente.
Grace a ces objets Future, on peut attendre la fin d'execution d'une tache ou l'annuler avant sa fin d'execution.

Cette normalisation met ainsi a disposition des outils simples & efficaces permettant de differer l'execution de taches et leur suivis.

Ca évite au final de refaire le monde a chaque fois que l'ont veut executer une tache dans un thread séparés ou qu'un veut mettre en place une queue d'execution.
07/08/2006, 16h49
Sergejack

Citation:

Envoyé par divxdede

pas tellement mais c'est tellement plus simple :)

Justement, cette simplicité n'implique-t-elle pas un coût au niveau des performances ?
Ce mécanisme a-t-il vraiment pour but de s'adresser au problème d'une écriture différée ?

J'ai l'impression que ça sert surtout quand one ne connait pas ou qu'il n'y a pas une séquence aux opérations.
Ici, c'est écriture, écriture, écriture, ..., écriture, cloture.
07/08/2006, 17h04
divxdede

Citation:

Envoyé par Sergejack

Justement, cette simplicité n'implique-t-elle pas un coût au niveau des performances ?
Ce mécanisme a-t-il vraiment pour but de s'adresser au problème d'une écriture différée ?

J'ai l'impression que ça sert surtout quand one ne connait pas ou qu'il n'y a pas une séquence aux opérations.
Ici, c'est écriture, écriture, écriture, ..., écriture, cloture.

Le niveau des performances ? je pense qu'il n'y as pas d'impact significatif a ce niveau. Mais je n'ai jamais effectué de comparatif donc ce n'est "qu'un sentiment".

Maintenant écrire un thread et la synchronisation qui va bien avec ce n'est pas dans ce cas trés compliqué et ce sera identique. J'ai utilisé ce "mécanisme" dans mon exemple car je voulais coder cet exemple trés rapidement (10 mins) et j'ai voulu eviter un maximum de codage.

Depuis que je connais java.util.concurrent je prefere de loin passer par ce genre d'outils que d'écrire mes Threads a la main mais ca n'engage en rien.
08/08/2006, 02h22
Sergejack

Citation:

Envoyé par divxdede

Le niveau des performances ? je pense qu'il n'y as pas d'impact significatif a ce niveau. Mais je n'ai jamais effectué de comparatif donc ce n'est "qu'un sentiment".

Maintenant écrire un thread et la synchronisation qui va bien avec ce n'est pas dans ce cas trés compliqué et ce sera identique. J'ai utilisé ce "mécanisme" dans mon exemple car je voulais coder cet exemple trés rapidement (10 mins) et j'ai voulu eviter un maximum de codage.

Depuis que je connais java.util.concurrent je prefere de loin passer par ce genre d'outils que d'écrire mes Threads a la main mais ca n'engage en rien.

Non, c'est cool, c'est instructif. :)
J'y reviendrai sans doute quand je ferai de la gestion de thread plus complexe.

PS: comme je ne pense pas que d'autres proposeront leur solutions, je marque le sujet comme résolu.