Синхронизация 2-х потоков. Помогите, скоро сессия vol. 2

[Sla]

Вад, дык я об этом и тылдычу, а он мені : "Вчитель так сказав"
Алексей1153++, почти, наверное прав.
Менеджером выступает, что-то, что инициирует потоки, в данном случае я пока увидел три потока (базука, снаряд, птичка) эти три потока не синхронны.

Птичка летит - два потока, но они последовательные, но не синхронны.

Хотя.... Пойду почитаю что-нибудь про синхронизацию. может я просто не понимаю что такое синхронная работа.

Т.е. для меня синхронизация - это приблизительно как синхронное плавание (прыжки в воду, на батуте)  два и более процессов делают одно и то же и в некие моменты они корректируют свои движения.
Также синхронизация - это когда независимые процессы в какой-то момент времени получают информацию от другого потока

Offtopic:

А тут анекдот про петуха и курицу:
Петух: Н едогоню так согреюсь
Курица: А не слишком ли я быстро бегу?

Поставлю в угол.

ничего не напомнило? в какой-то момент они засинхронизируются.

[Вад]

Ну, мы тоже в своё время делали подобные простенькие лабы, где нужно было наглядно демонстрировать, чтобы действия выполнялись потоками в очерёдности 1->2->..->N->1->2->..->N->... Поэтому мне понятно, почему именно так задание поставил преподаватель: чтобы студенты научились согласовывать работу потоков не только по принципу защиты данных критическими секциями, но и по принципу построения определённой требуемой очерёдности. Конкретно для двух потоков, если не предполагается как-то расширять эту схему, легче всего, на мой взгляд, для упорядочивания использовать схему, которую я выше описал. Возможно, есть схемы проще, но в голову они мне сейчас не приходят

[Sla]

Давайте отойдем от базуки и птички с ее крыльями. Ну никак не вкладывается махание крыльями в синхронизацию.

Живой пример:
Есть некая СУБД.
Есть некая запись.
Есть несколько процессов работающих с этой записью.

Чтобы привести конкретный пример - пожайлуста.
Банковский счет (БСч)
На Бсч лежит 1млн эквивалента.
Некий процесс (поток) П1 обращается к БСч и видит там 1 млн.
Другой поток П2 обращается к БСч и видит там 1 млн.
П1 снимает со счета половину от 1 млн.
П2 снимает со счета 0.75 от 1 млн.
Все! Банкиры в тюрьме!

Пытаемся исправить ситуацию.
П1 блокирует счет на время выполнения операций по состоянию БСч.
П2 ждет окончания блокировки. И только после окончания блокировки П2 получает доступ к состоянию БСч
Все. И волки целы и овцы сыты
 
Это то же синхронизация.
два потока работают до возникновения "критической ситуации" независимо, работают critical section. При возникновении критического события поток, ждет окончания "блокировки".

[Вад]

Согласен с приведённым примером. Но возможны же и другие ситуации, когда требуется обеспечить выполнение функций в разных потоках в определённой последовательности. Это не эквивалентные по своим задачам потоки (например, первый поток подготавливает какие-то данные для другого потока).
Пусть какой-то один компонент в своём потоке выполняет запросы к другому компоненту и ждёт ответа на отправленный запрос, прежде чем выполнять следующий запрос. В свою очередь, получатель запроса обрабатывает его, возвращая результат. Конечно, первый компонент может на свой страх и риск выполнять синхронный запрос ко второму, но ведь в случае необходимости отменить операцию управление потоком будет уже передано второму компоненту. А если совершение операции требует длительного времени? На мой взгляд, асинхронные запросы здесь более удобны. Сбрасываем событие получения ответа, отсылаем запрос, а по callback-у с результатом зажигаем эвент. В случае чего, сами устанавливаем событие получения ответа и восстанавливаем контроль над потоком (например, завершаем). Второй компонент в таком случае должен иметь свой собственный поток обработки запросов (хотя бы один), тогда при получении запроса он ставит этот запрос в очередь и зажигает свой эвент, освобождающий поток для обработки запроса. Поток выполняет обработку, вызывает нужный callback, передавая результат, и затем, если запросов больше не поступало, идёт спать в ожидании очередного события. Эта схема позволяет избавиться от частичной неуправляемости потока первого компонента, а также избежать лишних затрат на болтание в бесконечных циклах - каждый из двух потоков спит, пока его не разбудят по необходимости. Всё делается, если грубо, как раз на паре событий: первое событие - это событие завершения обработки запроса в первом компоненте, второе - событие получения запроса для обработки во втором компоненте.
Конечно, рассматриваемый в этой теме учебный пример с управлением крыльями птицы недостаточно нагляден - там придётся, видимо, реализовывать оба потока в рамках одного класса, - но суть схемы от этого особо не изменяется.

[Sla]

Вад, Все сводится к обработке событий (event). Есть событие разрешения - вперед продолжайте, нету -  сиди и не рыпайся, в крайнем случае, займись чем-нибудь, хоть тетрис собирай.