reedit parallel section

alimanfoo · alimanfoo · commit 2ec84e4c4ccb · 2017-11-22T21:33:34.000Z
diff --git a/docs/tutorial.rst b/docs/tutorial.rst
@@ -927,34 +927,24 @@ filters (e.g., byte-shuffle) have been applied.
 Parallel computing and synchronization
 --------------------------------------
 
-Zarr arrays have been designed for use as the source and/or sink for data in
-parallel computations. Please note that this is an area of ongoing research and
-development. If you are using Zarr for parallel computing, we welcome feedback,
-experience, discussion, ideas and advice, particularly about issues such as data
-integrity and performance.
-
-Both multi-threaded and multi-process parallelism are possible, although Zarr
-can use a number of different storage systems (see :ref:`tutorial_storage`) and
-not all storage systems support both types of parallelism. Please see the API
-docs for the :mod:`zarr.storage` module for more information about which storage
-classes support parellel computing.
-
-The bottleneck for most storage and retrieval operations is
-compression/decompression, and the Python global interpreter lock (GIL) is
-released wherever possible during these operations, so Zarr will generally not
-block other Python threads from running.
-
-Depending on how data are being accessed or updated, some synchronization
-(locking) may be required to avoid data loss. If an array is being read
-concurrently by multiple threads or processes, no synchronization is
-required. If an array is being written to concurrently by multiple threads or
-processes, some synchronization may be required, depending on the way the data
-is being written.
-
-If each worker in a parallel computation is writing to a separate region of the
-array, and if region boundaries are perfectly aligned with chunk boundaries,
-then no synchronization is required. However, if region and chunk boundaries are
-not perfectly aligned, then synchronization is required to avoid two workers
+Zarr arrays have been designed for use as the source or sink for data in
+parallel computations. By data source we mean that multiple concurrent read
+operations may occur. By data sink we mean that multiple concurrent write
+operations may occur, with each writer updating a different region of the
+array. Zarr arrays have **not** been designed for situations where multiple
+readers and writers are concurrently operating on the same array.
+
+Both multi-threaded and multi-process parallelism are possible. The bottleneck
+for most storage and retrieval operations is compression/decompression, and the
+Python global interpreter lock (GIL) is released wherever possible during these
+operations, so Zarr will generally not block other Python threads from running.
+
+When using a Zarr array as a data sink, some synchronization (locking) may be
+required to avoid data loss, depending on how data are being updated. If each
+worker in a parallel computation is writing to a separate region of the array,
+and if region boundaries are perfectly aligned with chunk boundaries, then no
+synchronization is required. However, if region and chunk boundaries are not
+perfectly aligned, then synchronization is required to avoid two workers
 attempting to modify the same chunk at the same time, which could result in data
 loss.
 
@@ -991,6 +981,11 @@ some networked file systems). E.g.::
 
 This array is safe to read or write from multiple processes.
 
+Please note that support for parallel computing is an area of ongoing research
+and development. If you are using Zarr for parallel computing, we welcome
+feedback, experience, discussion, ideas and advice, particularly about issues
+related to data integrity and performance.
+
 .. _tutorial_pickle:
 
 Pickle support
