Зачем нужен threading.Lock() ?

[feron]

Добрый день!

Не раз видел такую часть кода:

Код Выделить Развернуть

import threading
lock = threading.Lock()
dataListObj == []

// и где то в функциях которые работают в пуле потоков

with lock:
    dataListObj.append(result)

Но зачем так делать?

[Lemieux]

Конкурентный доступ к данным в многопоточных приложениях.

[feron]

Конкурентный доступ к данным в многопоточных приложениях.

Да, но зачем ? это разве не замедляет скорость помноженное на количество раз запуска ?
Почему без этой конструкции не обойтись ?

[Lemieux]

Да, но зачем ? это разве не замедляет скорость помноженное на количество раз запуска ?
Почему без этой конструкции не обойтись ?

Так Вы бы почитали, о чём я написал.
Если кратко. Например есть общие ресурсы, допустим массив, с которым работает N-е количество задач, запущенных в разных потоках. Нам нужно уберечься от того, что пока одна задача работает с элементом массива, другая задача не изменила его.
Вы можете спросить исходники saveraster у UU, и посмотрите как он реализовал конвертацию в несколько потоков.

[feron]

Вы можете спросить исходники saveraster у UU, и посмотрите как он реализовал конвертацию в несколько потоков.

ага, он прям взял и скинул 

Не не дело в том что я убрал эту конструкцию и все работает также..

Если кратко. Например есть общие ресурсы, допустим массив, с которым работает N-е количество задач, запущенных в разных потоках. Нам нужно уберечься от того, что пока одна задача работает с элементом массива, другая задача не изменила его.

я об этом так же и подумал, но там скорее всего есть своя очередь обработки этой переменной или нет ? вот например недавно сталкивался с скоростью записи на диск приложением, однако приложение не делает запись на диск на прямую..

Другое дело доступ к файлу на запись тут я согласен с этой конструкцией.

[Lemieux]

Не не дело в том что я убрал эту конструкцию и все работает также..

Смотря какой контекст. Вот если у Вас не будет работать в многопоточности, то это будут танцы с бубном.

я об этом так же и подумал, но там скорее всего есть своя очередь обработки этой переменной или нет ?

Гуглите о контексте приложения, мьютексах, семафорах, async/await.

Другое дело доступ к файлу на запись тут я согласен с этой конструкцией.

Многопоточные операции ввода/вывода это чуть другое.

[feron]

Гуглите о контексте приложения, мьютексах, семафорах, async/await.

Повторюсь - ведь python учел это в своем конструкции интерпретатора или нет ?

ответ: нет

There's no intermediate "queue" mechanism built into Python that would serialize these operations for you. If multiple threads modify the resource simultaneously without protection, you could encounter race conditions, where the final state of the data depends on the order in which the threads executed, leading to unpredictable results.

[p3452]

Но зачем так делать?

"Threading.Lock обеспечивает более высокую производительность по сравнению с традиционным классом Monitor. Это приводит к улучшению производительности в многопоточных приложениях. Для ещё большего повышения производительности рекомендуется удерживать блокировку в течение максимально короткого времени, чтобы сократить число конфликтов при блокировке."

[Vi2]

Threading.Lock обеспечивает более высокую производительность по сравнению с традиционным классом Monitor.

Вряд ли, там дело работы в нескольких строк. А вот без него геморроя предостаточно. "Вот же работает", значит, не попадает в критическую ситуацию. Но она не за горами. Или от многопоточности фиг да маленько.

PS
Правда, это не помогает/уберегает от повторно-входимых программ, которых при многопоточности много.

[feron]

Правда, это не помогает/уберегает от повторно-входимых программ, которых при многопоточности много.

А что же тогда поможет?

[Vi2]

А что же тогда поможет?

https://learn.microsoft.com/ru-ru/windows/win32/winauto/guarding-against-reentrancy-in-hook-functions