Multiprocessing package - torch.multiprocessing

参考    Multiprocessing package - torch.multiprocessing - 云+社区 - 腾讯云

 torch.multiprocessing是围绕本机多处理模块的包装器。它注册自定义约简器，使用共享内存在不同进程中提供对相同数据的共享视图。一旦张量/存储被移动到shared_memory(请参阅share_memory_())，就可以将它发送到其他进程，而不需要进行任何复制。

该API与原始模块100%兼容—只需更改导入多处理即可导入torch。多处理将所有张量通过队列发送或通过其他机制共享，移动到共享内存。由于api的相似性，我们不记录这个包的大部分内容，我们建议参考原始模块中非常好的文档。

Warning

如果主进程突然退出(例如，由于传入的信号)，Python的多处理有时无法清理其子进程。这是一个已知的警告，因此，如果你在中断解释器之后看到任何资源泄漏，这可能意味着这只是发生在你身上。

Strategy management

torch.multiprocessing.get_all_sharing_strategies()[source]

返回当前系统支持的一组共享策略。

torch.multiprocessing.get_sharing_strategy()[source]

返回共享CPU张量的当前策略。

torch.multiprocessing.set_sharing_strategy(new_strategy)[source]

设置共享CPU张量的策略。

Parameters

new_strategy (str) -所选策略的名称。应该是get_all_sharing_strategies()返回的值之一。

Sharing CUDA tensors

进程之间共享CUDA张量仅在python3中受支持，使用派生或forkserver启动方法。Python 2中的多处理只能使用fork创建子进程，而且CUDA运行时不支持它。与CPU张量不同，发送过程需要保持原始张量，只要接收过程保留张量的副本。refcount是在底层实现的，但要求用户遵循下一个最佳实践。

Warning

如果使用者进程非正常地死于一个致命的信号，那么只要发送进程在运行，共享张量就可以永远保存在内存中。

1. 尽快在用户中释放内存。

## Good
x = queue.get()
# do somethings with x
del x

## Bad
x = queue.get()
# do somethings with x
# do everything else (producer have to keep x in memory)

2. 保持生产者进程运行，直到所有消费者退出。这将防止生产者进程释放消费者仍在使用的内存的情况。

## producer
# send tensors, do something
event.wait()

## consumer
# receive tensors and use them
event.set()

不要传递接收到的张量。

# not going to work
x = queue.get()
queue_2.put(x)
 
# you need to create a process-local copy
x = queue.get()
x_clone = x.clone()
queue_2.put(x_clone)
 
# putting and getting from the same queue in the same process will likely end up with segfault
queue.put(tensor)
x = queue.get()

Sharing strategies

本节简要概述了不同的共享策略是如何工作的。注意，它只适用于CPU张量——CUDA张量总是使用CUDA API，因为这是它们可以共享的唯一方式。

File descriptor - file_descriptor

Note

这是默认策略(不支持macOS和OS X的情况除外)。此策略将使用文件描述符作为共享内存句柄。每当一个存储被移动到共享内存时，从shm_open获得的文件描述符就与该对象一起缓存，当它被发送到其他进程时，文件描述符将被传输到它(例如，通过UNIX套接字)。接收方还将缓存文件描述符并映射它，以获得存储数据上的共享视图。注意，如果有很多张量共享，这种策略将在大多数时间保持大量的文件描述符打开。如果您的系统对打开的文件描述符的数量有较低的限制，并且您不能提高它们，那么您应该使用file_system策略。

File system - file_system

该策略将使用指定给shm_open的文件名来标识共享内存区域。这样做的好处是不需要实现缓存从中获得的文件描述符，但同时容易出现共享内存泄漏。文件创建后不能立即删除，因为其他进程需要访问它才能打开它们的视图。如果进程致命地崩溃，或者被杀死，并且不调用存储析构函数，文件将保留在系统中。这是非常严重的，因为它们会一直使用内存，直到系统重新启动，或者手动释放它们。为了解决共享内存文件泄漏的问题，torch。多处理将生成一个名为torch_shm_manager的守护进程，该守护进程将自己与当前进程组隔离，并跟踪所有共享内存分配。一旦连接到它的所有进程退出，它将等待片刻以确保没有新的连接，并将迭代组分配的所有共享内存文件。如果它发现它们中的任何一个仍然存在，就会释放它们。我们对该方法进行了测试，证明该方法对各种故障具有较强的鲁棒性。不过，如果您的系统有足够高的限制，并且file_descriptor是受支持的策略，我们不建议切换到这个策略。

Spawning subprocesses

Note

该策略将使用指定给shm_open的文件名来标识共享内存区域。这样做的好处是不需要实现缓存从中获得的文件描述符，但同时容易出现共享内存泄漏。文件创建后不能立即删除，因为其他进程需要访问它才能打开它们的视图。如果进程致命地崩溃，或者被杀死，并且不调用存储析构函数，文件将保留在系统中。这是非常严重的，因为它们会一直使用内存，直到系统重新启动，或者手动释放它们。适用于Python >= 3.4。这取决于Python的多处理包中的spawn start方法。通过创建流程实例并调用join来等待它们的完成，可以生成许多子流程来执行某些功能。这种方法在处理单个子流程时工作得很好，但在处理多个流程时存在潜在问题。也就是说，按顺序连接进程意味着它们将按顺序终止。如果没有，并且第一个进程没有终止，则进程终止将不被注意。此外，没有用于错误传播的本机工具。下面的spawn函数处理这些问题，并处理错误传播、无序终止，并在检测到其中一个错误时主动终止进程。

torch.multiprocessing.spawn(fn, args=()， nprocs=1, join=True, daemon=False)[source]

生成使用args运行fn的nprocs进程。

如果其中一个进程以非零的退出状态退出，则其他进程将被终止，并引发一个异常，原因是终止。在子进程中捕获异常的情况下，将转发该异常并将其回溯包含在父进程中引发的异常中。

Parameters

• fn (function) –

  函数被称为派生进程的入口点。此函数必须在模块的顶层定义，以便对其进行pickle和派生。这是多处理强加的要求。该函数被称为fn(i， *args)，其中i是进程索引，args是通过参数元组传递的。

• args (tuple) – 参数传递给fn。

• nprocs (int) – 要生成的进程数。

• join (bool) – 对所有进程执行阻塞连接。

• daemon (bool) – 派生进程的守护进程标志。如果设置为True，将创建守护进程。

Returns

None if join is True, SpawnContext if join is False

class torch.multiprocessing.SpawnContext[source]

Returned by spawn() when called with join=False.

join(timeout=None)[source]

尝试在此派生上下文中联接一个或多个进程。如果其中一个进程以非零退出状态退出，则此函数将终止其余进程，并引发一个异常，原因是第一个进程退出。如果所有进程都已成功连接，则返回True;如果需要连接更多进程，则返回False。

Parameters

timeout (float) – Wait this long before giving up on waiting.