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

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

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

alert_1.join()

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

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()

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

понял

Благодарю.

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

я кукарекну ЛПП и удалюсь

Ок!

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

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

Зависит.

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

Прощаю тебе этот духовный выпад. А по делу - для затравочки:

http://en.cppreference.com/w/cpp/atomic/memory_order

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

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

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

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

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

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

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

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

FYI

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

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

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

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

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

Да, я про питон. Питоновская Queue имплементируется с локами. Самому локи в питоне писать не надо, если не хочешь отхватить дедлок, ибо уже все придомано до нас.

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

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