Python3 multiprocessing. Чтение-запись ячеек матрицы в общей памяти.

[MrTowelie]

Здравствуйте, интересует небольшой теоретический вопрос.
Собираюсь распараллелить часть своего кода, отвечающего за равномерное распределение случайно распределенных точек в объеме силами отталкивания.
В общей памяти будут содержаться координаты точек, заданные одномерными массивами, тип ячеек: float64.
В рамках программы устаревание данных не интересует, а разные ядра процессора не могут производить запись в одинаковые ячейки, но считывать могут все ячейки.

И вот здесь вопрос. Могут ли 2 разных ядра процессора одновременно производить и чтение, и запись числа из ОДНОЙ ОДИНАКОВОЙ ячейки матрицы в общей памяти? Т.е. может ли случиться так, что какое-то ядро прочитает не полностью записанное число, если такая запись вообще возможна? Или же два ядра встанут в очередь даже без явного её указания, обращаясь к одинаковой ячейке?

Вырезка кода задания общей памяти из другого моего кода (случай отличается, но принцип тот же):

Код: Выделить всё

import numpy as np
from multiprocessing import Process
from multiprocessing import shared_memory
if __name__ == '__main__':
    a=np.zeros((2, 12)) #вид матрицы памяти
    shm=shared_memory.SharedMemory(create=True, size=a.nbytes) #размер общей памяти
    b=np.ndarray(a.shape, dtype=a.dtype, buffer=shm.buf) #матрица, имеющая доступ в общую память
    b[:] = a[:] # заполнение общей памяти начальными данными

[WWolf]

MrTowelie, ну половинчатые данные не прочтёт, но за счёт буферизации или состояния гонки достоверности данных не будет. Нужны механизмы атомарного доступа.
Может питон это делает сам, но на С надо использовать семафоры/мьютексы/флаги

[slant]

MrTowelie, https://docs.python.org/3/glossary.html ... reter-lock

global interpreter lock
The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines.

Т.е. python в основном сам все умеет. По крайней мере это касается его встроенных типов данных.

Так же: https://docs.python.org/3/library/multi ... processing

multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads.

Т.е. писался специально с учетом GIL.

[MrTowelie]

Спасибо за ответы, пригодится эта информация в будущем.
Распараллелил эту часть кода. Система приходит к стабильному состоянию и выдаёт аналогичный однопоточному режиму ответ.