In current project, I'm using task scheduler to run a console application to perform some daily operations. Now, I am thinking to use the same console application for another operation that needed to be run every 15 minutes. To identify the operation in same console application, I'm planning to use different arguments. e.g.
MyProject.Services.exe "RunDailyTask"
MyProject.Services.exe "RunEvery15MinutesTask"
So, both schedulers will call the same exe but with different arguments to peform different operations.
My question is, will this be a good idea? Can one operation affect the other as both are sharing the same exe?
My question is, will this be a good idea? Can one operation affect the
other as both are sharing the same exe?
No, Console exe is executed in separate process. when you run multiple instances of the same exe application each of these instances are executed in it's on process.
If an instance fails, only that process is affected; applications in other processes continue to perform. Of course, because memory addresses in one process have no meaning in another process
You could simple test this by manually running two instances of your console application(by hard coding RunDailyTask and RunEvery15MinutesTask in each exe)
Also instead of passing string arguments to console it would be preferable to use number flags(1,2) within the executable you could use enumerations with meaningful values if needed.
enum OperationType
{
RunDailyTask = 1,
RunEvery15MinutesTask = 2
}
yes. good idea.
no. Can one operation affect the other as both are sharing the same exe?
windows run your applications by different instance (thread). of course you must be sure when RunEvery15MinutesTask must be finish its job before start RunDailyTask.
Related
I have created a Matlab dll that includes two functions. Function1 takes 3-4 millisecond to run and Function2 takes around 1 second. I need to run Function1 in C# continuously and Function2 time to time. I experienced that when I run Function2, Function1 does not run continuously or it takes a lot more than 3-4 millisecond (something in the range of 2-3 second). Function1 returns to normal/fast state as soon as Function2 is completed. These are what I already tried:
I called Function2 in a separate Thread, with no luck! (Function1 is also running in a separate Thread).
I used backgroundworker instead of Thread (just in case), with no luck!
I created a separate dll just for Function2, and again I experienced same issue/delay/latency.
Does anyone have any idea/solution for this problem? Does Matlab run functions/code in single thread? If not, is there anyway to specify separate thread for Functions?
I appreciate any help.
It seems like your intuition is correct: Calls to Matlab libraries are executed sequentially, even if originating from multiple threads. Refer to the comments by Peter Webb under Creating C++ Shared Libraries and DLLs:
You can call the libraries from multiple threads, but only one thread can be active in a library at any time. The generated libraries are protected by semaphores, which only allow one user thread into the generated library at any one time. Other user threads that try to call into the shared library will block (wait) until the shared library is “free”.
[...]
The libraries protect themselves with semaphores. They do so because the underlying execution engine (the MCR) is not thread safe. This means that even if you could disable the semaphores, you wouldn’t want to, since you’d likely get incorrect results or program failures.
If you truly need parallelism, currently your best (and only) option is to use separate processes. If your client can speak any of the standard web protocols (HTTP or JSON) or Microsoft’s proprietry extended versions, it’s pretty simple to set up web-based WCF clients in separate processes using WCF. (Of course, your servers have to run on Windows machines in that case.) See my WCF post for details.
I need to import different feeds at different times, and my plan is to set up separate scheduled tasks, i.e. one that runs weekly, one monthly and so on, with different arguments depending on which feeds should be run. My question is what the best practice is when doing that - should I check if the exe is still running for example? I know you can set up the scheduled task to queue up an instance if it's already running, but that only applies to the task and not the exe. I don't think it will be too process heavy, so it should be fine if several instances were running at the same time, but I'd just like to check in case I'm missing some obvious pitfalls.
Thanks,
Annelie
There won't be any issues with Task Scheduler. You can run the same executable in different tasks concurrently with no trouble.
There are potential issues in your application, of course. You'll want each separate instance to be writing to a different output file, or if they're using the same output file you'll need to synchronize access. Unless you're writing to a database, which will typically handle that synchronization for you.
One way to control a single instance of your application running is to use a Mutex. However, there shouldn't be any problem with just using the Task Scheduler for doing what you want - of course, this is all dependent on what your program is doing. You will have to handle synchronization depending on your program logic.
This question has some relevant information about using a Mutex for enforcing a single instance.
My issue is pretty simple.
I have an application that should be executed automatically once a day. I have no prior experience with this kind of scenario (some time ago I worked with IBM Control-M but guess that it is way more complete, complex and expensive =))
I thought about two possible solutions:
Creating a Task inside Windows Task Scheduler, which would execute the application;
Implement the application as a Window Service which would run 24/7, but only would perform the needed actions depending on the current time.
Which are the advantages/disadvantages of each approach?
Is there another way to do this?
Thanks in advance.
If it only executes once a day (or so) then just do it as a regular command line app that is executed by the windows task scheduler. Task scheduler already has all of the UI necessary to determine when to kick off the program, pass in parameters and anything else related to the scheduling of the task.
The only real reason to do this type of function as a windows service is if it needs higher execution resolution than once a minute. However, the main downside to a windows service is that you would have to manage the logic for how often/when to kick it off. Another one is that the app is always running, which leaves open the possibility for leaked memory if your code has issues.
On Unix/Linux you would use a cron job schedule a task to be executed. MS Windows' version is called the Task Scheduler and it is already a service that run 24/7 and performs the needed actions depending on the time.
Create a repeating task with the Task Scheduler to run your application. Creating, installing and configuring a service application is not exactly trivial. It's a much more involved process than creating a standard Forms or command line app and you don't need to do it anyway.
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
http://www.dotnetmonster.com/Uwe/Forum.aspx/dotnet-csharp/70633/Waitable-Timer-in-C
Another library that might be of interest is Quartz.NET
This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
windows service vs scheduled task
Windows Service Vs Simple Program
I'm trying to create a program that runs periodically (say every 5 minutes), or have the program running and have it execute the function within it (every 5 minutes).
The program is to obtain data from a database when it's executed and then write this to (for now) say info.txt file (no sensitive stuff is contained in here). each time it writes to the file it should overwrite the existing info within the file.
The program should also be started automatically at windows start up. (thus no need to login on the machine and to execute the .exe [if it's a normal program and not a service])
In between the periods that it executes the program would have nothing to do.
Therefore, should I run this program as a Windows Service, or should I use the Task Scheduler to periodically start the program to do this?
My goal is for this program to run as smooth as possible without clogging up resources. (eg. it shouldn't need more than 5% of the cpu)
I hope my question was clear enough.
I would go with application that is triggered by task scheduler. Only thing that you need to worry about is to run single instance of your application.
You can set task to run under specific user account and to run even if user is not logged on. There are number of events that can trigger task star like "Windows start", "System Idle"...
Other advantage is: If something crashes you can set task scheduler to send you an email or alert you in number of ways. You can control "exit code" of your application and signal to task scheduler what's going on and what to do.
There are a lot of positive features that task scheduler offers but not many people are using them.
I would suggest a Windows Service for this. Might be a good idea to create both and compare what the resource usage is like anyway?
I would actually recommend going for both depending on the requirements of the task you wish to run. I generally build most functionality for scheduled services into a single class library and then wrap it in a console application to start with and for debugging. When satisfied I wrap it in a windows service and forget about it.
Considerations of using a console app:
Make sure you run it under system account if possible or you can put in a specific login under Run as in scheduler. This will ensure an interactive login is not required.
If having 2 instances of it running at the same time is a problem, make sure you name it clearly and check for an instance of it running in your main method and exit if it is. A windows service will avoid this issue.
Considerations of using a window service
Make sure you're educated on thread usage. Windows services will use less resources if managed properly, but can be tricky if it's new to you and end up leaking memory in timer based tasks.
..there's a lot more to consider, but code it right and you can start with one and move to the 2nd when you're confident about it.
how to run different tasks in different process?
in my case I will have 2 tasks one runs every 1 mint the other will run every 10 mints
the point is each one is totally independent from the other
how to make them work within the same program?
The way I'd do it is to create a Windows Service that contains a Timer. The Timer checks at regular intervals if it is time to run each process, and when it is time to run starts each process using either
The ThreadPool class (if that's what I think you meant by different processes)
A new Process itself. You will have to have each function that needs to run compiled into a seperate executable and then you simply start it using this class.
Hope that helps!