I'm using the TaskRouter to create a Workspace, Tasks, Queues, Workers and Workflows.
When a Task enters a queue I need to perform some operations that may take up to a minute before I want the task to go to the next queue even if there's 0 available resources in it's current queue.
Is there a way to manually update the Task\Call to put it in another queue? Or is there a Workflow configuration to prevent the Task from moving to the next queue for a certain amount of time or specific conditions have been met?
TaskRouter engineer here!
Have a look at Workflow Timeouts in the docs. They allow the Task to sit in a target for a period of time before falling down to the next target (which may or may not move its Queue as well, depending on how you configure the next Target.
You also mentioned not waiting before moving on to the next Queue. For this you'd use a skip_if expression, which if evaluated to true immediately skips to the next target, regardless of the timeout.
Related
Going through the manual for Free RTOS, I encountered a sentence where it mentions
It is important to note that the end of a time slice is not the only
place that the scheduler can select a new task to run; as will be
demonstrated throughout this book, the scheduler will also select a
new task to run immediately after the currently executing task enters
the Blocked state, or when an interrupt moves a higher priority task
into the Ready state.
I am confused with the way preemption works in Free RTOS. Consider a task A with priority 1 is in RUNNING state. Also consider task B with higher priority 2 enters READY state when the task A is in the middle of the time slice.
Q1: What type of interrupt is the manual talking about?
Q2: Is the interrupt only way to take the task B to READY state while the task A is in RUNNING state?
Q3: If answer to Q2 is no, when would the task switching occur if it is not interrupt driven? Is it after the time slot ends or is it immediately at the middle of the time slice without waiting for the end of time slice?
You describe the following situation where you have two tasks with different priorities:
Task A with priority 1 (lower), currently in RUNNING state
Task B with priority 2 (higher), entering READY state
In this situation, it's important to ask yourself a question - what would be the possible scenarios that would lead to this situation?
The general rule of a thumb when dealing with tasks of different priorities in FreeRTOS is that the higher priority task will be given all the available time, unless it cannot run due to being SUSPENDED, BLOCKED (waiting for queue, semaphore, mutex) or put in a delay (this also falls into BLOCKED state). Therefore in your case - task A would never enter RUNNING state unless task B was previously either SUSPENDED or BLOCKED.
To answer your questions:
Q1: What type of interrupt is the manual talking about?
I'd assume they're talking about a situation where task B is in a blocked state due to waiting for semaphore/queue and you "give a semaphore" / "send to quque" from an interrupt. Examples of this happening: IO level interrupt giving a semaphore, UART interrupt pushing received byte into a queue.
Q2: Is the interrupt only way to take the task B to READY state while the task A is in RUNNING state?
I'd say no. Other examples that come to mind (apart from the interrupt cases mentioned above):
Task B is SUSPENDED and task A decides to resume task B. When you do so, task B should resume execution immediately and take all the available time from this point on, unless it again enters SUSPENDED or BLOCKED state.
Task B is waiting for a mutex held by task A and task A releases it.
Task B is waiting on a semaphore/queue and task A "gives semaphore", "sends to queue".
Task B was in a delay and that delay ended.
Q3: If answer to Q2 is no, when would the task switching occur if it is not interrupt driven? Is it after the time slot ends or is it immediately at the middle of the time slice without waiting for the end of time slice?
I already listed possible examples above. To mention it again - when you have two tasks with different priorities, then unless the higher priority task gets into BLOCKED or SUSPENDED state, it'll take all available time from the lower priority task. While technically you can still speak of "time slices" in this case, all of the slices will be assigned/consumed by higher priority task. Therefore, speaking of "time slicing" only really makes sense when you have two or more tasks running with same priority, in which case time should be split between them evenly (unless they get BLOCKED or SUSPENDED).
I'm completely new with FreeRTOS. I have two tasks: the first one must be performed continuously in the loop and the second one should turn on only after interrupt and after the second one is done it should return to the first one, which needs to start from the beginning(it's important because the first task collects data and if I continue to perform it from the place where I interrupt I will get the trash.).
Can I use Semaphore for it or is there something better? Thank you in advance.
It is not clear what you are asking or what you want to use the semaphore for. Protecting data access by both the interrupt and the first task? Or maybe signaling the first task? From what I can make out it sounds like you want to have a lower priority task running continuously, then when an interrupt occurs have the interrupt handler unblock a higher priority task that will then preempt the lower priority task and execute. Then when it finishes and blocks again the scheduler will naturally continue running the lower priority task. I'm confused by your statement that if you continue executing from where it was interrupted you will get trash though - interrupts always return to where they interrupted.
The most efficient way of unblocking a task from an interrupt would be a direct-to-task notification. I would also recommend reading some of the generic FreeRTOS documentation and books available on the FreeRTOS.org site.
Inside my Rails 4 application I need to make API calls to a webservice where I can ask for an instance of stock quotes. I can ask for 1000 stocks in one request and four requests at a time which is the throttle limit.
The workflow goes like this:
A user makes a request to my app and wants to get quotes for 12000 stocks.
So I chunk it into twelve requests and put them in a Queue.
At application start I start a thread in a loop which is supposed to look at the queue and since I am allowed to make concurrent requests I'd like to make 4 requests in parallel.
I get stuck in several ways. First of all I need to take into consideration that I can get multiple requests of 12000 stocks at a time since different users can trigger the same request.
Second, I ll use the Thin web server wjich is multithreaded. So I guess I have to use a Mutex.
How can this be achieved?
Queues are already threadsafe data structures, so you don't need a mutex to work with them.
You'd just start 4 threads at the start of your app, which each poll the queue for work, do some work, and then do something (which is up to you) to notify the DB and/or user that the work is complete. The actual workers will be something like:
work_queue = Queue.new
4.times do
Thread.new do
loop do
job = work_queue.pop
# Do some work with the job
end
end
end
Queue#pop blocks until data is available, so you can just fire off those queues and the first thread waiting for data will get the job when it's pushed in, the next thread will get the next job, and so on. While there are no worker threads available, jobs will accumulate in the queue.
What you actually do with the output of the job is probably the more interesting question here, but you haven't defined what should happen when the quotes are retrieved.
You might also look at Sidekiq.
When certain conditions are met, I'd like to schedule a worker to run a particular job in 5 minutes. The thing is, if the same conditions are met again, I want to check if there's something scheduled to run. If there is such a worker scheduled to run, then, I don't want to enqueue again, but if there isn't, it should be queued. I hope you guys understood what I'm trying to do. Can it be achieved? If yes, how?
Sounds like you want to use or implement a simple persisted lock. The code that enqueues the job can first check for the availability of the lock, acquire and enqueue if available, skip if not. The enqueued job can be responsible for releasing the lock. You'll want to account for failure, like adding a lock timeout. The redis-mutex gem may be a useful implementation of this idea.
Best practices promote jobs that are idempotent. This means that you should be writing them in such a way that it should be safe to run them more than once. Any subsequent call doesn't change the result of the first call. You achieve this by writing logic that does the proper checks, and acts accordingly. Since you don't provide a description of what your worker does, I can't be more specific.
For an example, here is a link to the Sidekiq's FAQ: Make your workers idempotent and transactional
The benefit of this approach is that you're playing along the convenient abstraction of scheduled workers, instead of fighting against it.
I am using GCD on iOS to perform a a time-consuming task on a background thread. The API has a start method that takes two blocks as arguments, both called on the main queue. The first is called when the task starts and the second when the task finishes. This all works.
I actually need to do several of these time-consuming tasks. The API lets me start them all at the same time and then wait for each to finish and update the UI via the blocks. They run concurrently.
However what I actually I want to do is to sequence the time-consuming tasks (still starting each using the API described) so that I can start them all at the same time, have the first one run and give me its call-backs, then have the second one run and give me its call-backs, etc. until all are done.
What is the best way to achieve this with GCD and blocks?
If the tasks were synchronous, I'd just have a loop that ran each in turn, and run all of that asynchronously. But I have call-backs, so that will not work. I'd prefer not to have to chain them, since the object that makes all of this happen could disappear once it has started the sequence of events.
You can create your own serial queue that will execute in FIFO order with dispatch_queue_create. You DO NOT need to specify that it is a serial queue. It will act this way by default.
Sample queue creation:
dispatch_queue_t my_q = dispatch_queue_create("Serial",NULL);
You own this queue, so failing to release it (with dispatch_release) will leak it.
More info is in Apple's docs here.
Is there a particular reason you have to use GCD? Sounds like NSOperationQueue with concurrency of 1 is exactly what you want.