I have several concurrent asynchronous network operations, and want to be notified after all of them finished receiving the data.
The current thread shall not be blocked, synchronous connections aren't an option, and all operations shall be executed concurrently.
How can I achieve that? Or is it more performant to execute all network operations successively, particularly looking at mobile devices?
Related
according to apple's doc, tasks are still started in the order in which they were added to a concurrent queue, so it seems to me that there is no difference between a concurrent queue vs a serial queue where all its task are run by async.
correct me if I miss something
read bunch of documents and did not find the answer
The difference is how many tasks may run at the same time:
A serial queue only processes (runs) one task at time, one after another. A concurrent queue may process multiple tasks (on multiple thread) at the same time.
You typically use a serial queue to ensure only one task is accessing a resource at the same time. These are scenarios where you would traditionally use mutexes.
If you have tasks that would benefit from (and are able to) running concurrently at the same time, or tasks that are completely independent and thus don't care, you usually use a concurrent queue.
I have 5 tasks(function) in 5 different which are running simultaneously. I want to implement like any function start running then other function should not run until the function completes its process.
I want to implement using FreeRTOS.
Example.
foo1.c
->Task1
foo2.c
->Task2
foo3.c
->Task3
foo4.c
->Task4
foo5.c
->Task5
It sounds like you need a mutex. Each task acquires the mutex when they start running, and release it when they are done. When any of the tasks is running, others are blocked on the mutex.
You need to use a mutex (mutually exclusive) semaphore.
Here is an example protecting the Serial Port of an ATmega Arduino Clone. This ensures that messages presented to the serial port by multiple tasks are not interleaved (corrupted).
You can see that the semaphore is taken before attempting to write to the serial port, and then given (freed) when the task has completed its activities.
I've been using a DispatchGroup to facilitate a number of concurrent calls in my app.
My backend team noticed that when I tried to make eight concurrent calls, they were separated into two batches of four calls.
Is four concurrent calls the limit for GCD?
Is this a limitation of the GCD framework, or is this dependent on the hardware?
Is there a way to allow for more concurrent calls?
From the reference for GCD:
Concurrent queues (also known as a type of global dispatch queue)
execute one or more tasks concurrently, but tasks are still started in
the order in which they were added to the queue. The currently
executing tasks run on distinct threads that are managed by the
dispatch queue. The exact number of tasks executing at any given point
is variable and depends on system conditions.
The system automatically (and dynamically) determines how many tasks to execute simultaneously. Among other things it's based on battery state, # of cores, system load, etc.
See Dispatch Queues for more information.
fetchMessagesByNumberOperationWithFolder(path, requestKind: requestKind, numbers: indexSet)
From my understanding, the queue of "MCOIMAPFetchMessagesOperation" are managed by the imapSession.
Is it possible / recommended to have 2 MCOIMAPFetchMessagesOperation running concurrently to download messages more quickly?
I've read this:
Running simultaneous operations in Mailcore2
but it seems like the question is running simultaneous but different operations concurrently whereas what I want to do is run simultaneous operation of the same kind to speed up the whole process
I have a controller action that aggregates data from multiple sources: web service, database, file lookups, etc... and passes results to the view. So in order to render the page all tasks must have completed. Currently they are performed sequentially but as they are independent I am thinking of running them in parallel as this could improve performance.
So what would be the best approach to achieve this? For each task start a new thread and block the main thread as all tasks are finished? Should I use a thread from the thread pool or spawn a new thread manually? Using threads from the thread pool would limit my web server's capability of serving new requests so this might not be a good idea. Spawning new threads manually could be expensive, so at the end of the day would there be a net gain in performance by paralleling these tasks or just leave them run sequentially?
If it's between spawning your own threads or using the thread pool threads, I'd say use the ones from the thread pool. You can always adjust your server settings to allow for more threads in the pool if you find that you are running out of threads.
The only way to answer your final question would be to actually test it out, as we don't know how complicated the separate aggregation tasks are. If you want to give the illusion of a responsive UI, you could always display the loading page and kick off the aggregation with AJAX. Even non-threaded, this may placate your users sufficiently.