Should I use a CriticalSection on WriteFile calls?

I have an application in Windows CE that creates multiple threads that can at any time make a call to a log function that uses a WriteFile call. Should I use a CriticalSection around the WriteFile call and/or all the internals of the api that uses the WriteFile function or does WriteFile handle the proper sequence when multiple threads call it?

Who is Participating?
jkrConnect With a Mentor Commented:
>>does WriteFile handle the proper sequence when multiple threads call it?

In simple words: Since all Windows APIs are reentrant, it is safe to assume that this one is, too. You have to take care of synchronizing access to a file yourself, so a critical section is actually a good solution.
Frosty555Connect With a Mentor Commented:
I would not count on WriteFile handling race conditions for you. Assuming you have opened the file for writing once in your application, and all of your threads reference the same shared file handler, then yes you need a critical section.

If you have each thread independently creating new file handles with OpenFile() each time they want to write to the logfile, then the situation is slightly different. In this case, when one thread opens the file it will lock it for writing. If another thread  tries to open the same file it will fail with an "access denied" error because the file is in use. Critical sections will also help fix this, but proper error handling in the event of not being able to open the file for any reason (not enough disk space, file doesn't exist, hanging file handler from an old process etc.) is still necessary.

JimBeveridgeConnect With a Mentor Commented:
Calling WriteFile() from multiple threads isn't going to crash Windows (or even crash your process), but there's no guarantee that data will be written in the desired order, or whether a particular data block will be written atomically. So you can end up with a mess.

Opening a file handle when your app starts and then writing from different threads using critical sections is a fine solution. The only downside is that you may need to flush the data after each write so that no data wil be lost if your app crashes.

If you open and close the file for each write to the log, Frosty555 is correct that you can rely on file sharing to prevent you from accessing the file, but there's no way to be automatically notified when the file becomes available. The only solution is to continually retry opening the file and sleep between each attempt. Not a great solution unless it's just debug code. Far better to use a critical section.

Alternatives for logging that avoid contention problems:
- Make each thread write to a separate file where each new entry has a timestamp, then merge the files later.
- Create a dedicated thread for logging and that thread is the only thread that writes to the file. Bump its priority to make sure it runs often enough. You can send data to it using a FIFO queue protected with a critical section.
atomicgs12Author Commented:
These are all good answers. I never know how to give out points. jkr was first with an answer but Frosty555 and JimDeveridge both gave additional useable commnets. What do you guys suggest?
You can split the points as you see fit. You don't have to award all of the points to one person.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.