Multithreading and syncronization

[Guest]

I have written a dll that performs file IO that will be called frequently. I
have been running into problems where file locking is occuring when a thread
cannot access the file since it is being used. How do I lock this IO
operation down while it is being used and tell the other threads to wait
until the IO is complete - like waiting in a checkout line? I have looked
into numerous examples, but just cannot find anything that relates to file IO
that works.


lock(this)
{
System.Threading.Monitor.Enter(this);
FileStream fs = new FileStream(fileName, FileMode.OpenOrCreate,
FileAccess.ReadWrite);
StreamWriter sw = new StreamWriter(fs);
sw.BaseStream.Seek(0, SeekOrigin.End);
sw.WriteLine("etcetc");
sw.Flush();
sw.Close();

System.Threading.Monitor.Pulse(this);
System.Threading.Monitor.Exit(this);
}

Any help is appreciated, I am new to threading.

 

[Jon Skeet [C# MVP]]

I have written a dll that performs file IO that will be called frequently. I
have been running into problems where file locking is occuring when a thread
cannot access the file since it is being used. How do I lock this IO
operation down while it is being used and tell the other threads to wait
until the IO is complete - like waiting in a checkout line? I have looked
into numerous examples, but just cannot find anything that relates to file IO
that works.

Well, it's not *really* an IO-specific problem.

lock(this)
{
System.Threading.Monitor.Enter(this);

There's no need to use Monitor.Enter if you've already got "lock" -
they're equivalent. (I wouldn't recommend locking on "this" though.)

I suggest you use a semaphore for each resource - there's no semaphore
in .NET pre-2.0, but it's fairly easy to write one. (There may well be
one available on the web.)

 

[Ken Kolda]

You're on the right track, but there are a couple of changes you need to
make and a few issues to be aware of.

1) You should remove all the calls to the Monitor object. The "lock"
statement is equivalent to calling Monitor.Enter() when the block starts and
Monitor.Exit() when the block ends. The Monitor.Pulse() call is only useful
when you also use Monitor.Wait(), but I don't think you need either for what
you're doing.

2) Because you're using "this" as your synchronization object, your code
will only ensure concurrent access to the file for threads accessing the
same instance of whatever class contains the code below. If your class will
have multiple instances which all need to be synchronized, then use "lock
(this.GetType())". This will lock on the class's Type object, which is
shared for all instances, thus synchronizing all instances of the class.

3) Even if you make the change in item #2, this makes the assumption that
the only code that will attempt to access this file is within this one
class. If you have other code in other classes that may access the same
file, then you need to ensure synchronization regardless of which class
accesses the file. To do this, I'd recommend breaking the file access code
into a new class so that all accesses go through there. Then locking on the
object's type should work.

4) All of that said, none of this protects you against locks held by other
processes. I don't know of any way to have the code block until a filesystem
lock is released. To simulate this, you can try to open the file, catch the
IOException, perhaps call Thread.Sleep for a second or so and try again.

Hope that helps -
Ken

 

[mirek]

I have written a dll that performs file IO that will be called frequently. I
have been running into problems where file locking is occuring when a thread
cannot access the file since it is being used. How do I lock this IO
operation down while it is being used and tell the other threads to wait
until the IO is complete - like waiting in a checkout line? I have looked
into numerous examples, but just cannot find anything that relates to file IO
that works.

Hi, I'm complete newbie in C# lang. I know this problem fom another platform. My solution was this:

implement sync object which is type of a queue

- your thread will add itself to this queue and then goes to sleep
- will be wakened by queue when is ready to write
- after writing, remove self from queue (call a method queue.remove(me))- this operation will tell the queue, that another process should be wakened ...