Normally, a computer system only has a timer(hardware), and it trigger the system bu interrupts. But on application layer, we can set multiple tasks based on timer, like cron jobs. I am just wondering how system utilize the timer(hardware) to implement the application tasks(cron jobs, or java scheduled tasks).
Thanks
Single timer, set to go off when the next task is up. Then it's set for the task after that, and so on, and so on.
In most cases, it's not even a timer hooked up to an interrupt, but a thread polling with Sleep delays.
Related
My entire application's state depends on the quartz scheduler.
I am running a daily job which runs every 24 hours and updates the application state based on the logic written in job's execution function.
While testing, I found that sometimes when the system gets heavily loaded, scheduler do not work and the state does not change.
When I was running scheduler for every second and keeps system heavily loaded I was able to reproduce this case frequently.
Is there any way to ensure that quartz scheduler is running always?
What causes transition of process from one state to another state if non-preemptive multitasking scheme is being used to manage multiple tasks in the system?
Suppose a process is in running state. Now it moves to waiting state for I/O. In that case, another ready process will be context switched and will be executed.
I am using signals to intercept celery beat tasks before publishing. This works fine. But, in addition I want to execute some logic and, based on the result, possibly cancel the task.
I cannot find a way to cancel the task from the event handler, aside from raising an exception and that seems very inelegant.
The background is that I am implementing distributed task processing using cache locks and I am performing CAS operations on the lock before publishing.
Is there any way to implement this using current celery/celerybeat functionality?
Thanks
I'm looking for a lightweight system that will let me queue up a one-off (non-recurring) task and have it execute at a specific time in the future.
This is for the backend of a game where the user does tasks that are time-based. I need the server to check the status of the user's "job" at the completion time and perform the necessary housekeeping on their game state.
I'm somewhat familiar with Redis, Celery, Beanstalkd, ZeroMQ, et al., but I haven't found any info on scheduling a single unit of work to be executed in the future. (or pop off the queue at a set time) Celerybeat has a scheduler for cron-type recurring tasks, but I didn't see anything for one-off.
I've also seen the "at" command in *nix, but I'm not aware of any frontend for it that can help me manage the jobs.
I realize there are some easy solutions such as ordering keys in Redis and doing a blocking pop, but I'd like to not have to continuously poll a queue to see if the next job is ready.
The closest I've found is the deferred library on GAE, but I was hoping for something that runs on my own Linux box along with my other components.
I'd appreciate any suggestions!
Celery allows you to specify a countdown or an ETA at the call of a task to be executed.
The documentation says it best:
http://docs.celeryproject.org/en/latest/userguide/calling.html#eta-and-countdown
How is the multitasking implemented at the basic level ? To clarify my question, lets say we are given a C runtime to make an application which implements multitasking, which can run only one task at a time on a single core processor, say, by calling main() function of this "mutlitasking" application.
How do standard OS kernels implement this ? How does this change with multicore processors
OS sets an interrupt timer, and lets the program run. Once the timer expires, control flow jumps to code of the OS for context switch.
On the context switch OS saves registers and supporting data of the current process and replaces it in CPU with data of the next process in queue. Then it sets another interrupt timer and let the next program run from where it was interrupted.
Also a system call from the current process gives control to the OS to decide if it is time for a context switch (eq. process is waiting for an IO operation)
The mechanics is transparent for programs.
Run. Switch. Repeat. :)
I've not done much work with multi-core processors, so I will refrain from attempting to answer that part of the query. However, with uniprocessors, two strategies come to mind when it comes to multi-tasking.
If I remember correctly, the x86 supports hardware task switching. (I've had minimal experience with this type of multi-tasking.) From what I recall, when the processor detects the conditions for a task switch, it automatically saves all the registers of the outgoing task into its Task State Segment (x86), and loads all the registers from the incoming task's Task State Segment. There are various caveats and limitations with this approach such as the 'busy bit' being set and only being able to switched back to a 'busy task' under special conditions. Personally, I do not find this method to be particularly useful to me.
The more common solution that I have seen is task switching by software. This, can be broken down into cooperative task switching and pre-emptive task switching. If you are coding up a cooperative task switching strategy, a task switch only occurs when the task voluntarily gives up the processor. In this strategy, you only need to save and load the non-volatile registers. If a pre-emptive strategy is chosen, then a task switch can occur either voluntarily, or non-voluntarily. In this case, all the registers must be saved and loaded. When coding either scenario, you have to pay extra care that you do not corrupt your register contents and that you set up your stack correctly so that when you return from task-switching code you are at the right place on the stack of the incoming task.
Hope this helps.