# Parallel Task Examples for Treasure Workflow

In Treasure Workflow, you can have tasks run in parallel. By default, tasks are run sequentially. To have Treasure Workflow tasks run in parallel, you must specify the parallel parameter as `_parallel: True`. It is also recommended that you use the `+group` syntax to group the tasks that you want to have run in parallel.

You can define as many tasks as you want to run in parallel, however, TD can only run up to 10 separate processing threads at a given time. Tasks can have one of four different states, only one of which is Running. As long as only ten tasks have concurrent states of running each of those tasks is executed in parallel.

In this topic:

* [Parallel Task Order Example](/products/customer-data-platform/data-workbench/workflows/parallel-task-examples-for-td-workflow#parallel-task-order-example)
* [Default Task Order Example](/products/customer-data-platform/data-workbench/workflows/parallel-task-examples-for-td-workflow#default-task-order-example)


Workflow `_parallel` option supports entering the number of tasks to run in parallel.

With the option of `_parallel : true` there is no limit that users can specify on the number of tasks to run in parallel, which could potentially result in tasks that have many sub-tasks all run in parallel blocking the tasks queues.

The enhancement gives the user the control to manage running parallel tasks & better manage the resource utilization.

## Parallel Task Order Example

The following example groups two tasks and has them running in parallel.

```yaml
+group:
  _parallel: True
  +step1:
    echo>: "hello!"
  +step2:
    py>: tasks.printMessage
    docker:
      image: "digdag/digdagpython:3.9"
  +step3: 
    td_run>: my_other_saved_query
```

With the current option of `_parallel : true` there is no limit that users can specify the number of tasks to run in parallel, which might potentially result in tasks that have many sub-tasks all running in parallel and blocking the tasks queues.

A workflow `_parallel` option supports entering the number of tasks to run in parallel.

```yaml
+group:
  _parallel:
    limit: 2
  +step1:
    echo>: "hello!"
  +step2:
    py>: tasks.printMessage
    docker:
      image: "digdag/digdagpython:3.9"
  +step3: 
    td_run>: my_other_saved_query
```

When you set a `limit`, tasks run in groups of that size. All tasks in a group must finish before the next group starts. To start the next task as soon as one task finishes, set the `eager` option to `true`.

```yaml
+group:
  _parallel:
    limit: 2
    eager: true
  +step1:
    echo>: "hello!"
  +step2:
    py>: tasks.printMessage
    docker:
      image: "digdag/digdagpython:3.9"
  +step3:
    td_run>: my_other_saved_query
```

With `eager: true`, up to 2 tasks run at the same time. When one task finishes, the next task starts immediately, so the number of running tasks stays at the limit until all tasks finish. A failed task does not block the other tasks in the group. The remaining tasks run to completion, the group fails after all tasks finish, and only the failed tasks run when the attempt is resumed. If you want the group to stop as soon as a task fails, do not set `eager: true`.

When a workflow sets `_parallel` with `eager: true` at the top level of the file and also sets `sla:`, the tasks that the SLA adds when it triggers join the eager group. These tasks start only when a free slot is available, so they may not run immediately. To avoid the delay, group the tasks with the `+group` syntax and set `_parallel` on the group instead of the top level.

## Default Task Order Example

For example by default, in the following workflow, task step1 is executed first and because there is a custom script included in the step, the Python program `tasks.printMessage` runs in a separate Docker container, and when it completes, the subsequent task in step 2 executes.

```yaml
+step1:
 echo>: "hello!"
+step2:
  py>: tasks.printMessage
  docker:
    image: "digdag/digdagpython:3.9"
+step3:
  td_run>: my_other_saved_query
```

Treasure Workflow runs until all tasks complete. Long-running tasks that go beyond the set TTL (Time To Live) are timed out. Even if the task is executing a custom script. Periodically the task is polled to check on the status of the script running in the container and log messages can be seen on the Treasure Console and CLI using the `td wf log <attemptid>` command.