Multithreading and ReadFile() / WriteFile()

[Halloko]

I'm experiencing some problems with writing data to a driver of mine and I was wondering if it is caused by the following:

I open a single handle to the driver with CreateFile(). I use the handle in both ReadFile() and WriteFile() which are called in separate threads.
Now, what I'm wondering is if this approach has some multithreading issues (because both threads use the same handle) and if I should instead open two handles to the driver.

Thanks!

[kirants]

No problem. You can use the same handle from multiple threads.

[Halloko]

Hmm, I just got the following reply some place else:
A file handle only has 1 'current offset' value which is the location that the next read or write will take place at in the file. You will likely trash your file using the same handle in more than 1 thread unless you guard the handle (e.g. critical section) and always set the offset before a read/write.

What to believe :|

[golanshahar]

Hmm, I just got the following reply some place else:


What to believe :|

Your question was whether you can use same handle to a file in two threads (like kiran told to you - you can ).

Now, critical section is a must and this apply to any resource you want to use in multithreading - not just file handle.

Cheers

[Halloko]

Right :)

I'd better add a critical section (or similar) or open two handles.

Thanks!

[NoHero]

[ Moved Thread ]

[Halloko]

A small additional question on performance.

Wouldn't it faster just to open two handles instead of having to use critical regions? I mean, with the first approach each thread can read/write as much as they desire, whereas using critical regions only allows one of the threads to do I/O at any instant.

Also, when using overlapped I/O and you call e.g. GetOverlappedResult() to wait for the operation to complete, you would still be in the critical region and could potentially cause the other thread to wait quite some time.

[kirants]

Hmm, I just got the following reply some place else:
What to believe :|
Believe what is true ;)
The statement is about handles which represent files. Yours is a handle to a driver and I believe it is one which communicates to some hardware.. and my guess is , a seek operation is meaningless to such handles.

About opening multiple handles, I don't know. For one, understand that to open multiple handles, you would have to open the device with shared attribute. This itself leaves it open for other applications other than yours to open it. This may not be what you want.

About having to guard your handle with critical sections, I am not sure you need that. My guess is, one doesn't need to do that. Normally, drivers implement seperate read/write buffers and you don't have to ensure that the read/writes are synchronized. This is my gut feel which I would have to verify.

Generally, what you need to do is to guard the read actions within critical sections, so multiple threads do not read ( this again to avoid your application from falling into data inconsistency and not due to the shared handle as such ) . Same goes with writes.

[Halloko]

Generally, what you need to do is to guard the read actions within critical sections, so multiple threads do not read ( this again to avoid your application from falling into data inconsistency and not due to the shared handle as such ) . Same goes with writes.
Good point. Luckily I only have one thread reading, and one thread writing. :)