Writing to a file from more than one thread possible?

  • Thread starter Thread starter Terry Olsen
  • Start date Start date
T

Terry Olsen

I need to be able to write to a file simultaneously from approximately 4
different threads. I'm working on a program that will download parts of a
file and combine the parts. Each thread will have an offset from zero and a
length to write. None of the threads will overlap in the file position.

Is it possible to have the file open (shared) by multiple threads? I'm
guessing that i'd use a filestream with some sort of sharing. Looking for
some pointers and/or examples. Thanks!
 
Terry,

I don't think multiple threads can have the same file open. I use the
below class to allow threads in my multithreaded apps to write to the
same file. The synclock prevents them from having it at the same time.
I expect you can use something like this to allow them first come
first serve to the file.


Public Class MyStringLogger
Private Shared m_loglock As New Object

Public Shared Sub Write(ByVal fileName As String, ByVal
strToWrite As String)
SyncLock (m_loglock)
Try
Dim sw As New System.io.StreamWriter(fileName, True)
sw.WriteLine(strToWrite)
sw.Close()
Catch
End Try
End SyncLock
End Sub
End Class
 
You can have separate thread or singleton managing the file. Just pass data
from your threads to file managing thread (delegates or messages) and you
should be pretty safe.
 
I need to be able to write to a file simultaneously from approximately
4 different threads. I'm working on a program that will download parts
of a file and combine the parts. Each thread will have an offset from
zero and a length to write. None of the threads will overlap in the
file position.

Is it possible to have the file open (shared) by multiple threads? I'm
guessing that i'd use a filestream with some sort of sharing. Looking
for some pointers and/or examples. Thanks!
Click to expand...

Wouldn't it just be simpler to have the multiple threads write to different
files and combine them at the end by creating the final file at this point,
drawing it's data from these other file in sequence?
 
Wouldn't it just be simpler to have the multiple threads write to
different files and combine them at the end by creating the final file at
this point, drawing it's data from these other file in sequence?
Click to expand...

No, I'm using a program that does that right now and it creates thousands of
small files and then combines them when it's all done. This causes constant
hard drive activity and my computer is unusable while the program is doing
this. So i'm trying to duplicate the program and combine the data on the
fly, only writing the one file on the hard drive.

I've been leaning toward having one "file manager" thread that I pass a byte
array & file offset and let it do the writing.
 
I'm just curious why you chose four threads. I mean, if you want something
optimal, I would think the thread count is based on a buffer size. In
theory, I doubt the question matters if there was two or twenty-two threads.
 
Because I'm downloading yEncoded files from a usenet news group. Nothing
shifty here, perfectly legal. Grabbing Fan-Made Mission files from
alt.binaries.games.thief

My news server allows 4 connections. So i'll be simultaneously downloading 4
parts of the file at a time, yDecoding them on the fly, and writing the
decoded bytes to the file.

Some news servers allow upwards of 10 to 20 connections, so it's possible
that someone else using the program may have that many threads running and
all trying to write to the file.

I've built a FileWriter class that lets me pass the Filename, byte array,
file offset, and length. I used SyncLock to make sure each thread waits its
turn. Thanks to the guy who made that suggestion. I haven't tested it yet
but I have high hopes that it will work well.
 
Terry said:
Because I'm downloading yEncoded files from a usenet news group.
Nothing shifty here, perfectly legal. Grabbing Fan-Made Mission files
from alt.binaries.games.thief

My news server allows 4 connections. So i'll be simultaneously
downloading 4 parts of the file at a time, yDecoding them on the fly,
and writing the decoded bytes to the file.
Click to expand...

But surely, using 4 connections won't make it download any faster? Isn't the
download speed limited by the speed of your Internet connection? I suppose
it might even make it slower as the disk drive head on the news server has
to keep moving between four parts of the file.

Andrew
 
I'm sorry. For some reason I had thought you were talking about four
System.Threading.Threads, not discussion threads.
 
I've been leaning toward having one "file manager" thread that I pass
a byte array & file offset and let it do the writing.
Click to expand...

Sounds interesting. Hows about adding each ByteArray or stream to a queue
together with a description of it s destination byterange. Then your filemanager
can be the only thread to write to the file and can deal with the bytearrays/streams
as they are completed and added to said queue.
 
But surely, using 4 connections won't make it download any faster? Isn't
the download speed limited by the speed of your Internet connection? I
suppose it might even make it slower as the disk drive head on the news
server has to keep moving between four parts of the file.
Click to expand...

I have an 8MB cable connection. The news server caps each connection to
40kbs. So 4 connections gives me 160kps effective speed.

And the news server shouldn't have any problem with the disk drive heads as
the ISP has hundreds of thousands of subscribers, many, i'm sure, use the
newsgroups.
 
ModelBuilder said:
I'm sorry. For some reason I had thought you were talking about four
System.Threading.Threads, not discussion threads.
Click to expand...

You were correct. I'll have 4 System.Threading.Threads running, each
downloading a part of the file.
 
Terry said:
I have an 8MB cable connection. The news server caps each connection
to 40kbs. So 4 connections gives me 160kps effective speed.
Click to expand...

That makes sense then :-)

The only constructive suggestion I have is that it might be helpful to do a
..SetLength on the filestream, which I would hope would throw an exception if
there wasn't enough disk space.

Andrew
 
Back
Top