LINUX.ORG.RU

многопоточность питон

 ,


0

2

есть например вот две функции :

import threading
def fun1(msg):
    print(msg+"-1")
def fun2(msg):
    print(msg+"-2")
alert_1 = threading.Thread(target=fun1, name="msg", args=["text"])
alert_1.start()
alert_2 = threading.Thread(target=fun2, name="msg", args=["text"])
alert_2.start()
все работает , но мне нужно что бы fun2 запускался только после завершения работы fun1,а у меня есть подозрения что это не так , кто что подскажет ?зарание спасибо.


Это же конкаренси, без явной синхронизации событий никаких предположений об очерёдности событий делать нельзя. Используй Event, Lock, запуск fun2 в конце fun1...

true_admin ★★★★★ ()

Очередь сообщений тебя спасёт. Локи не нужны, ты не ос пишешь.

Один поток write only в queue, например, второй read only. Никаких гонок, ибо эксклюзивные раздельные права на чтение и запись у разных потоков.

slaykovsky ★★★ ()
Ответ на: комментарий от deadNightTiger

то есть вы предлагаете сделать что то тип :

import threading
def fun1(msg):
    print(msg+"-1")
def fun2(msg):
    print(msg+"-2")
alert_1 = threading.Thread(target=fun1, name="msg", args=["text"])
alert_1=join()
alert_1.start()
alert_2 = threading.Thread(target=fun2, name="msg", args=["text"])
alert_2.start()

если я ошибаюсь то пожалуйста поправьте

echo_ ()

import threading
def fun1(msg):
    print(msg+"-1")
def fun2(msg):
    print(msg+"-2")
alert_1 = threading.Thread(target=fun1, name="msg", args=["text"])
alert_1.start()
# здесь то, что ты хочешь делать, пока работает первый поток
alert_1.join()
alert_2 = threading.Thread(target=fun2, name="msg", args=["text"])
alert_2.start()
eternal_sorrow ★★★★★ ()
Ответ на: комментарий от slaykovsky

вообще, ЛПП. Но в случае с питоном с его моделью памяти - прокатит.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)

мне нужно что бы fun2 запускался только после завершения работы fun1

В этом случае fun2 надо запустить после fun1 в том же потоке.

vzzo ★★★ ()
Ответ на: комментарий от mersinvald

Вроде как в питоне гарантируется, что чтение-запись в память sequentially consistent. Для остальных сред компиляции/выполнения гарантии значительно более слабые. Поэтому для питона должно прокатить. Если ошибаюсь насчёт питона - уточни/поправь.

dzidzitop ★★ ()
Ответ на: комментарий от dzidzitop

тема про пиздон
кидает какую-то доку для крестов

Окче, я тебе этот выпад прощаю.

slaykovsky ★★★ ()
Ответ на: комментарий от slaykovsky

Не хочешь просвящаться - не надо. Вдумчивый читатель обнаружит, что ссылка про процессоры и компиляторы, а не про плюсы.

А так же про то, что твои рассуждения не работают на живых компиляторах и железе:

Один поток write only в queue, например, второй read only. Никаких гонок, ибо эксклюзивные раздельные права на чтение и запись у разных потоков.

Но исключительно для питона, если не ошибаюсь, прокатит.

Ключевые слова: out-of-order execution, writeback buffer, cache coherency, memory barrier

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 2)
Ответ на: комментарий от dzidzitop

Тут не было вопростов про железо, ало. Был вопрос про питон. Как лучше тредам сообщаться в питоне. В питоне лучше message queue с формальным разграничением прав не придумали.

FYI

Ключевые слова: out-of-order execution, writeback buffer, cache coherency, memory barrier

Это все здорово, что ты знаешь такие умные слова, но речь идет о питоне и вникать в low-level bullshit у меня нет ни времени, ни желания.

slaykovsky ★★★ ()
Последнее исправление: slaykovsky (всего исправлений: 1)
Ответ на: комментарий от slaykovsky

Я отвечал исключительно на процитированную выше фразу, где не было ни слова о питоне. С питоном (который вроде как sequentially consistent по спеке) описанные выше message queue будет работать и без локов. Но эта логика за пределами питона неверна.

Так что если ты рассуждал в рамках исключительно питона, то ок.

А ютубчик посмотрю под чипсон, спасибо.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Полностью согласен, прочитал «не прокатит», звиняюсь.

mersinvald ★★★★ ()
Ответ на: комментарий от slaykovsky

Скорее, свою мультитредную очередь не надо писать и локи на доступ к самому контейнеру типа «очередь» не нужны в большинстве случаев. А с локами на элементы очереди и прочим low-level bullshit всё от условий использования зависит.

dzidzitop ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.