I’ve been experimenting with this activity, but it doesn’t actually seem to do anything truly parallel for me. Instead, it appears to behave exactly like a sequence, with the activities being executed from left to right. The Microsoft documentation on this activity states that it should be able to do multiple things at the same time.
I’ve searched the forum and downloaded some .xaml examples but even then, the code is not actually executed in a parallel manner. The only advantage I can see with this activity is code readability.
Can anyone shed some light on this? I don’t understand what it’s supposed to do, and if it actually works in UiPath. It doesn’t seem to work.
You are right. It performs the steps from left to right and doesn’t actually do anything truly at the same time. And, if it gets stuck on one side, it is still stuck. This also means that both sides will not end at the same time so you need to use a loop that ends when the longer side ends, depending on what you need it for.
One thing you could try however, is use an Invoke Workflow in the parallel. I have not played with this enough but have heard it works better that way.
The “Parallel” activity seems to be designed to invoke workflows, it doesn’t work if you put activities inside.
Example below. I created 3 workflows, each with a delay of 5, 10 and 15 seconds after which a message box popped up. When I ran this, all three messageboxes popped up one after the other with a 5 second interval, exactly as expected. This is very interesting stuff, will definitely look into it. As long as workflows don’t interfere with each other you can make a robot do multiple things at the same time.
@ UiPath, it would be nice if the Parallel activity is documented.
Parallelization truly works only for async activities and a lot of what is normally used is not async (invokes obviously are).
What happens under the hood is that each branch, starting from left, is started and executor switches to the next one whenever main thread is unblocked - that happens on async call or end of branch.
If there’s no async calls it will execute fully sequentially, as you noticed, but that’s not the fault of Parallel but what is put inside its execution scope.
So in essence, unless you’re invoking separate workflows in it, it should be treated not as “do all of this at once” but “whenever you’re idle do things from other branches”. Like a human multitasking.
Parallelization is not an easy thing and since the activity itself doesn’t know what’s inside of it, it’s implementation has to be pretty defensive and it will switch branches only when specifically allowed by an async call.
Pick branches work on the same basis.
i didnt experience this with Parallel activity…actually I think it does what the MS documentation says it does !
in fact what i had was a parallel activity having two branches… the first branch was executing an extraction from a web browser, the second branch worked in parallel to work on that data extraction … simply doing a count of dataset records and sleeping for 2 seconds.they definitely was working in parallel.
While all the Activity objects run asynchronously, they do not execute on separate threads, so each successive activity only executes when the previously scheduled activity completes or goes idle. If none of the child activities of this activity go idle, this activity execute in the same way that a Sequence activity does.
Sleep (or Delay activity) is async, so it releases control (goes idle).
ExtractData is also async, so it also releases control (goes idle).
Hence with that execution context Parallel will work “as expected”.
Check with attached file - first parallel has no asyncs (Message boxes used as blocker examples), second parallel has asyncs (delays of 1ms). Observe that branches switch when they encounter an async activity (clearly visible when running in debug and stepping). ParallelTest.xaml (19.6 KB)
If you use invokes, you’re introducing threading (or mult-process, if using Isolated), thus execution contextes are completely separate and you don’t need to worry if something is async or not, since it’s no longer running in same thread/process (and thus can’t block itself).
Do keep in mind that if used incorrectly, multithreading and multiprocessing might introduce issues, including (but not limited to):
WIth multithreading most common error is that one parallel execution changes something that the second one was using in unexpected way or moment, producing hard to track errors
With multiprocessing all data passed between them has to be serializable (since they don’t share same memory space)
WIth both it is possible to have deadlocks (that is - both execution contexts are waiting for each other and none of them does anything, essentially creating a hang in the application without any error message)
Anil_G
raja.arslankhan
Shivam_Rana
u322805
Sathish_Kumar_S
Arvind_Kumar1
Camila_Caldas