Introduction

In older TensorFlow 1.x systems, queue-based input pipelines were a common way to feed data into training jobs. In distributed training, a natural question is whether several workers can consume from the same queue. The short answer is yes in some TensorFlow 1.x graph setups, but it is usually not the design you want, and in modern TensorFlow 2 the preferred answer is to use tf.data sharding or data services instead of shared queues.

What “Shared Queue” Means in TensorFlow

In TensorFlow 1.x, a queue such as FIFOQueue or RandomShuffleQueue is a stateful resource in the graph. If that queue is placed on one task and multiple workers can reach it, those workers can enqueue or dequeue from the same shared resource.

Conceptually, that means the queue is not copied per worker. It lives in one place, and remote workers interact with it through the distributed graph.

That makes sharing possible, but it also introduces central coordination and network traffic.

Why a Shared Queue Is Usually a Bad Fit

A single shared queue can become:

• a bottleneck, because all workers contend for one resource
• a single point of failure, because if the hosting task dies, input stalls
• a source of uneven throughput, because faster workers may consume more aggressively than slower ones
• harder to debug than local worker pipelines

Distributed training generally scales better when each worker reads its own shard of the dataset instead of fighting over one central queue.

Modern TensorFlow Approach: Shard the Dataset

In TensorFlow 2, tf.data is the standard input pipeline API. Instead of manually managing queues, each worker typically gets its own dataset shard.

1import tensorflow as tf
2
3worker_index = 1
4num_workers = 4
5
6dataset = tf.data.Dataset.range(100)
7dataset = dataset.shard(num_shards=num_workers, index=worker_index)
8dataset = dataset.batch(8)
9
10for batch in dataset.take(3):
11    print(batch.numpy())

This avoids central queue contention and makes it obvious which worker reads which slice of the data.

Distributed Training with MultiWorkerMirroredStrategy

A common modern pattern is to build the dataset once and let TensorFlow distribute it with worker-aware sharding.

1import tensorflow as tf
2
3strategy = tf.distribute.MultiWorkerMirroredStrategy()
4
5dataset = tf.data.Dataset.range(1000).shuffle(1000).batch(32)
6
7with strategy.scope():
8    model = tf.keras.Sequential([
9        tf.keras.layers.Dense(16, activation="relu"),
10        tf.keras.layers.Dense(1)
11    ])
12    model.compile(optimizer="adam", loss="mse")

In practice, you combine this with dataset options or file-based sharding so workers do not all read the exact same examples unless that is intentional.

If You Are Stuck on TensorFlow 1.x

If you are maintaining an older graph-based system, then yes, a shared queue can be placed on a device such as a parameter-server task or another designated host. Multiple workers can dequeue from it. But you need to think through capacity, coordination, and failure behavior.

In many TF1 deployments, engineers eventually moved away from a single shared queue because scaling and operability were poor compared with per-worker readers.

Common Pitfalls

• Assuming “possible” means “recommended” for distributed input design.
• Building a single queue that becomes the training bottleneck.
• Forgetting fault tolerance when the queue resource lives on one remote task.
• Letting workers read overlapping data unintentionally.
• Using queue-based TF1 designs for new TensorFlow 2 code instead of tf.data.
• Ignoring dataset sharding and then wondering why scaling is poor.

Summary

• In TensorFlow 1.x, multiple workers can technically share one queue resource in a distributed graph.
• That design is usually harder to scale and operate than per-worker input pipelines.
• In TensorFlow 2, prefer tf.data, dataset sharding, or data services.
• Shared queues centralize coordination and can become bottlenecks.
• Choose an input pipeline design that scales with worker count instead of concentrating traffic in one place.