I have a console application that is run by taking the input parameters. It can be configured by passing report name parameter, for e.g. reportgen.exe sales.xml. It hits the database and retrieves the data into xml file and sends to sftp site.

Whole of this process is logged and the xml files are being saved in a directory. This exe needs to be scheduled on daily basis, so what happens if the exe is scheduled at same time with different parameters.

Is it thread safe and can be considered as independent execution doing what it supposed to do?

Edit: It uses log4net for logging the debug info. into a file. So, how does it write log statements into single file for concurrent executions.

  • look at how external resources are accessed, if code is thread safe - then nothing to worry about.
    – Yusubov
    Aug 14, 2013 at 14:54

3 Answers 3


Well it depends how you have programmed your application. We can view a couple of pitfalls, you can find on your way.


The first problem can happen in the database. Your application access the database, retrieve data from various tables and then start processing the data. But suddenly the application comes to a halt. Certain data seems to be inconsistent. What happened here?

What happened is, that you loaded your data from various tables without using transactions. The database is not able to provide read consistency and somebody else updated one of the tables.

Thus run the critical queries in one transaction, so your database can provide the consistency you need.

The second problem happens on filesystem level. While you save you save your xml file, another instance of the program is writing at the same time. This will corrupt the file, because two writers can make quite a mess.

While your use case doesn't point to this situation, it is still worth securing.

This is easily solvable by using file locking. A exclusive write lock will save this for you. Nobody can read the file and only you can write it. Or you have to wait on the other program.

The last thing you can do, is create a pidfile (process id file) for your program, but I don't think it is needed here. So if you run a different instance, it can check another instance is running and then goes into a waiting mode until the pidfile is given free. You can lock the pidfile as above, but then with a shared lock. If your program hangs, then you can kill it easily by reading the pidfile and kill the process.

In pseudocode you do this:



As mentioned here log4net can't do concurrent writes to a single log file:



Your code will be thread safe as it's running within different process instances.

What's you'll need to be careful with is there you log to. Make sure the various instances don't try to create log files with the same name, otherwise you'll have problems.


Each instance of your application will be loaded into its own application domain.
They will be separated from each other.
You can find more information about Application Domains on MSDN - Application Domains (C# Programming Guide)

If you're dealing with a lockable resource which obtains a lock when operation starts, and releases a lock when operation ends (either on OS or application level), then you must have a single point of access.
You can't use singleton pattern here because each instance of your application will be loaded into its own application domain, and singleton has AppDomain scope. ok?

So, if you can't use singleton, what can you do?

Well, you can create another application to communicate with lockable resource and all communication between your application (multiple instances of your application) and lockable resource must go through that application.

  • While technically true (because each process has its own AppDomains), this has actually nothing to do with AppDomains.
    – svick
    Aug 14, 2013 at 16:17
  • @svick, thank you for your down-vote :) I've updated the answer. I hope it makes more sense now.
    – šljaker
    Aug 14, 2013 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.