О чем необходимо знать и понимать чтобы использовать систему быстрого потока
О чем необходимо знать и понимать чтобы использовать систему быстрого потока
ПОТОКИ И РАСШИРЕНИЕ. СИСТЕМА БЫСТРОГО ПОТОКА
В последних инструктивных письмах по организационной политике мы ввели много новых принципов администрирования. Вот один из принципов, и, если его упустить, возникает тайна.
Это принцип потоков частиц, который мы сейчас применяем. Он называется «СИСТЕМА УПРАВЛЕНИЯ ПО ПРИНЦИПУ БЫСТРОГО ПОТОКА».
Человек, контролирующий поток частиц или ход деятельности, должен позволять потоку идти до тех пор, пока его не понадобится укрепить или пока не обнаружатся показатели того, что в нём появляется какая-то взбудораженность, – и только затем он инспектирует ту его часть, которую требуется укрепить или которая начинает энтурбулироваться, и он проводит инспекции только одного этого потока или хода только этой деятельности и предпринимает действия только в отношении их.
В комитете из трёх человек этот принцип действовал бы следующим образом.
Комитет не работает как единый орган. Каждый член комитета действует индивидуально в трёх сферах влияния (в трёх типах потоков). Нет действия комитета (коллективного) до тех пор, пока один из трёх членов комитета не захочет, чтобы два других с ним взаимодействовали с целью значительного укрепления какого-нибудь потока, или пока двое других, понаблюдав, не заметят, что третий сбился с курса. Только в этих случаях комитет действует как комитет. Другими словами, все три члена комитета занимаются своей работой независимо друг от друга до тех пор, пока в одной из их трёх сфер не появится изменение, вот тогда они действуют.
В остальных случаях потоки приказов и действий независимы друг от друга.
Невыполнение этого таким образом – вот причина того, что о комитетах стали думать, что они неспособны ничего сделать, и того, что созывать их считается тратой времени.
Для того чтобы это выполнить, конечно же, необходимо ещё одно – показатели.
Показатель – это то, что сообщает о приближающемся изменении, а не то, что обнаруживает изменение, которое уже имеет место и подтвердилось.
Мы это взяли из одитинга. Одитор одитирует, пока всё идёт гладко. Он знает о том, что дела вот-вот начнут ухудшаться или изменяться, по какому-либо показателю. Увидев показатель, одитор предпринимает действия. Он не дожидается, пока преклир дойдёт до слома или пока состояние преклира не изменится полностью, а потом изучает это и предпринимает действия. Одитормог бы заодитировать преклира сверх меры или пренебречь хорошим процессом, который улучшал кейс, если бы он не мог, исходя из показателей, ПРЕДСКАЗАТЬ, что произойдёт, до того как это произойдёт.
В случае осуществления надзора за деятельностью ряда секций или отделов это будет работать следующим образом.
Начальник не изучает каждое действие или решение на линиях. Если бы все послания всех сфер деятельности проходили через его руки, такой объём был бы слишком большим и создал бы пробку. Забот у руководителя было бы «выше крыши», и это прекратило бы любое расширение данных сфер деятельности, так как руководитель чувствовал бы, что он перегружен работой, хотя в действительности доводил бы до конца очень мало дел. Потоки, за которыми необходимо было следить, окажутся погребёнными под огромным количеством потоков, следить за которыми было не нужно.
Вместо этого принцип потоков говорит нам о том, что руководитель должен иметь ПОКАЗАТЕЛИ статистик, такие, как еженедельные графики ИЦО по каждому участку деятельности, и должен действовать только исходя из того, что показывают графики ИЦО.
Если график пошёл вниз, руководитель не станет ждать, когда произойдёт крушение этой области, прежде чем провести в ней инспекцию. В момент небольшого падения руководитель должен изучить все планы, движение частиц и послания в области, в которой происходит небольшое падение, и раскопать настоящую причину, по которой это происходит. Если ситуация требует принятия лишь незначительных мер, необходимо произвести коррекцию. Если после этого график по-прежнему показывает падение, руководителю не только на это укажут показатели ИЦО, но он будет знать, поскольку он уже провёл инспекцию, какие более жёсткие меры необходимо принять, чтобы график вновь пошёл вверх.
Система ИЦО должна использоваться, и все данные должны наноситься на графики и передаваться руководителям в организации, прежде чем эта система заработает.
Когда система ИЦО введена в действие полностью, тогда (и только тогда) руководитель может выпустить коммуникационные линии из своих рук и позволить частицам течь.
Затем ему будет необходимо только:
Единственная вещь, которую не должен делать руководитель, – это «становиться рассудительным» по поводу падений и взлётов и вследствие этого не предпринимать действий, для того чтобы по-настоящему остановить падение или усилить подъём:
а) думать, что в самом деле знаешь, хотя не провёл тщательной инспекции,
б) не доверять графикам и показателям и
в) не предпринимать действий, – всё это фатальные ошибки.
Если выполняются шаги с 1 по 5, то это говорит нам о том, что перед нами руководитель, а если выполняются а), б) и в), то это говорит нам о том, что человек не должен быть руководителем.
Если эта система в действии, то организация просто не может не прийти к расцвету.
Мы называем это «СИСТЕМОЙ УПРАВЛЕНИЯ ПО ПРИНЦИПУ БЫСТРОГО ПОТОКА».
Это очень тонкое искусство. Как одитинг. Вы предсказываете падения и усиливаете движение в направлении расцвета.
Система не может дать сбой, если вышеуказанное выполняется полностью.
Оргсхема. Как разработать структуру компании
Скорее всего вам знакомо такое состояние, когда по дороге на работу вы строите планы, выделяете приоритетные задачи, от решения которых зависит долгосрочный успех компании, но приехав в офис, оказываетесь заваленными кучей «срочных вопросов», а задуманные планы так и не воплощаются в жизнь. В конце рабочего дня такой руководитель, отрывая взгляд от рабочего стола, даже не может вспомнить, чем он занимался весь день. А самые главные задачи приходится решать уже после того, как работники пошли домой отдыхать.
Однажды я консультировал руководителя компании по разработке программного обеспечения для автоматизации учета. Работая с ним, я заметил, что в момент, когда у нас были перерывы, он не мог оторваться от компьютера. Оказывается, он ежедневно получал более 150 сообщений по электронной почте. Понаблюдав за этим некоторое время, я решил выяснить, что это за частицы, которые в таком количестве ему приходиться обрабатывать. Он рассказал, что когда его компания состояла из нескольких программистов, чтобы согласовывать действия, они решили ставить друг друга в копию важных писем, касающихся рабочих проектов. Может быть в самом начале это было неплохой идеей и помогало им согласовывать действия, но постепенно компания росла, а практика «ставить в копию» осталась. Через несколько лет, руководителю приходилось ежедневно просматривать более сотни сообщений, основная часть которых вообще уже не относилась к его функциям.
Командные линии проходят сверху вниз, через всю цепочку руководителей. Коммуникационные идут напрямую, от одного сотрудника к другому. Если директор компании хочет, чтобы продавец изменил что-то в своей работе с какими-то клиентами, он отдает распоряжение, которое проходит через начальника отдела Продаж, а тот передает его продавцу и добивается исполнения, а получив от него доклад об исполнении, проверяет его и направляет директору. Частицы сначала в виде распоряжения и затем в виде отчета идут по командной линии сверху вниз и снизу вверх.
Если посмотреть на оргсхему из семи отделений, несложно обнаружить, что Техническое отделение склонно меньше всего забрасывать частицы на доработку руководителю. Так, например, в строительной компании никому не придет в голову попросить директора закончить заливку фундамента или окраску стены. Но в административных областях, например в продажах, распространенной практикой является принести на рабочий стол руководителя незаконченную продажу с вопросом от том, что делать с клиентом, который требует скидку. Или со стороны менеджера по персоналу, вывалить на рабочий стол руководителя предварительно отобранные резюме кандидатов с предложением сделать окончательный выбор. Удивительно, но по сути это то же самое, что: «Закончи, пожалуйста, за нас покраску забора, босс!»
Впервые узнав из статьи Рона Хаббарда 26 о коммуникационных и командных линиях, я решил проанализировать, какие частицы мне, как директору компании, приходится обрабатывать. Результатом этого анализа я был поражен, оказалось, что как минимум 60% своего времени я тратил на работу, которая вообще не относилась к обязанностям руководителя. Это время уходило на работу с коммуникационными частицами, которые могли двигаться напрямую от одного сотрудника к другому, а не через меня.
В нашей компании основная часть общения происходит по электронной почте, а чтобы было проще использовать систему быстрого потока существуют определенные правила составления посланий:
Должен быть указан тип послания: распоряжение, отчет о выполнении, информационное сообщение, запрос или что-то другое.
Обязательно должна быть явно указана тема, чтобы в последствии можно было легко найти это послание.
Человеку, не понимающему, как устроена организация, такие правила могут показаться надуманными, может возникать ощущение, что происходит «бюрократизация». Бюрократией называют положение дел, когда руководители и сотрудники увлечены соблюдением формальностей и прячутся за этими формальностями, пренебрегая выполнением своей работы. Бюрократия происходит не тогда, когда используется много различных форм документов, а тогда, когда частицы движутся по запутанным маршрутам, содержащим ненужные промежуточные пункты, и действий из-за этого останавливаются, а для выполнения самых обычных действий необходимо получать ненужные одобрения.
была вывешена в доступном для всех месте оргсхема;
за каждую из функций оргсхемы был назначен ответственный сотрудник;
каждый сотрудник знал разницу между командными и коммуникационными линиями;
форма используемых посланий позволяла легко определить, к какой линии относится частица.
О чем необходимо знать и понимать чтобы использовать систему быстрого потока
ПОТОКИ И РАСШИРЕНИЕ. СИСТЕМА БЫСТРОГО ПОТОКА
В последних инструктивных письмах по организационной политике мы ввели много новых принципов администрирования. Вот один из принципов, и, если его упустить, возникает тайна.
Это принцип потоков частиц, который мы сейчас применяем. Он называется «СИСТЕМА УПРАВЛЕНИЯ ПО ПРИНЦИПУ БЫСТРОГО ПОТОКА».
Человек, контролирующий поток частиц или ход деятельности, должен позволять потоку идти до тех пор, пока его не понадобится укрепить или пока не обнаружатся показатели того, что в нём появляется какая-то взбудораженность, – и только затем он инспектирует ту его часть, которую требуется укрепить или которая начинает энтурбулироваться, и он проводит инспекции только одного этого потока или хода только этой деятельности и предпринимает действия только в отношении их.
В комитете из трёх человек этот принцип действовал бы следующим образом.
Комитет не работает как единый орган. Каждый член комитета действует индивидуально в трёх сферах влияния (в трёх типах потоков). Нет действия комитета (коллективного) до тех пор, пока один из трёх членов комитета не захочет, чтобы два других с ним взаимодействовали с целью значительного укрепления какого-нибудь потока, или пока двое других, понаблюдав, не заметят, что третий сбился с курса. Только в этих случаях комитет действует как комитет. Другими словами, все три члена комитета занимаются своей работой независимо друг от друга до тех пор, пока в одной из их трёх сфер не появится изменение, вот тогда они действуют.
В остальных случаях потоки приказов и действий независимы друг от друга.
Невыполнение этого таким образом – вот причина того, что о комитетах стали думать, что они неспособны ничего сделать, и того, что созывать их считается тратой времени.
Для того чтобы это выполнить, конечно же, необходимо ещё одно – показатели.
Показатель – это то, что сообщает о приближающемся изменении, а не то, что обнаруживает изменение, которое уже имеет место и подтвердилось.
Мы это взяли из одитинга. Одитор одитирует, пока всё идёт гладко. Он знает о том, что дела вот-вот начнут ухудшаться или изменяться, по какому-либо показателю. Увидев показатель, одитор предпринимает действия. Он не дожидается, пока преклир дойдёт до слома или пока состояние преклира не изменится полностью, а потом изучает это и предпринимает действия. Одитормог бы заодитировать преклира сверх меры или пренебречь хорошим процессом, который улучшал кейс, если бы он не мог, исходя из показателей, ПРЕДСКАЗАТЬ, что произойдёт, до того как это произойдёт.
В случае осуществления надзора за деятельностью ряда секций или отделов это будет работать следующим образом.
Начальник не изучает каждое действие или решение на линиях. Если бы все послания всех сфер деятельности проходили через его руки, такой объём был бы слишком большим и создал бы пробку. Забот у руководителя было бы «выше крыши», и это прекратило бы любое расширение данных сфер деятельности, так как руководитель чувствовал бы, что он перегружен работой, хотя в действительности доводил бы до конца очень мало дел. Потоки, за которыми необходимо было следить, окажутся погребёнными под огромным количеством потоков, следить за которыми было не нужно.
Вместо этого принцип потоков говорит нам о том, что руководитель должен иметь ПОКАЗАТЕЛИ статистик, такие, как еженедельные графики ИЦО по каждому участку деятельности, и должен действовать только исходя из того, что показывают графики ИЦО.
Если график пошёл вниз, руководитель не станет ждать, когда произойдёт крушение этой области, прежде чем провести в ней инспекцию. В момент небольшого падения руководитель должен изучить все планы, движение частиц и послания в области, в которой происходит небольшое падение, и раскопать настоящую причину, по которой это происходит. Если ситуация требует принятия лишь незначительных мер, необходимо произвести коррекцию. Если после этого график по-прежнему показывает падение, руководителю не только на это укажут показатели ИЦО, но он будет знать, поскольку он уже провёл инспекцию, какие более жёсткие меры необходимо принять, чтобы график вновь пошёл вверх.
Система ИЦО должна использоваться, и все данные должны наноситься на графики и передаваться руководителям в организации, прежде чем эта система заработает.
Когда система ИЦО введена в действие полностью, тогда (и только тогда) руководитель может выпустить коммуникационные линии из своих рук и позволить частицам течь.
Затем ему будет необходимо только:
Единственная вещь, которую не должен делать руководитель, – это «становиться рассудительным» по поводу падений и взлётов и вследствие этого не предпринимать действий, для того чтобы по-настоящему остановить падение или усилить подъём:
а) думать, что в самом деле знаешь, хотя не провёл тщательной инспекции,
б) не доверять графикам и показателям и
в) не предпринимать действий, – всё это фатальные ошибки.
Если выполняются шаги с 1 по 5, то это говорит нам о том, что перед нами руководитель, а если выполняются а), б) и в), то это говорит нам о том, что человек не должен быть руководителем.
Если эта система в действии, то организация просто не может не прийти к расцвету.
Мы называем это «СИСТЕМОЙ УПРАВЛЕНИЯ ПО ПРИНЦИПУ БЫСТРОГО ПОТОКА».
Это очень тонкое искусство. Как одитинг. Вы предсказываете падения и усиливаете движение в направлении расцвета.
Система не может дать сбой, если вышеуказанное выполняется полностью.
Внутри процесса: многопоточность и пинг-понг mutex’ом
Какая тема вызывает больше всего вопросов и затруднений у начинающих? Когда я спросила об этом преподавателя и Java-программиста Александра Пряхина, он сразу ответил: «Многопоточность». Спасибо ему за идею и помощь в подготовке этой статьи!
Мы заглянем во внутренний мир приложения и его процессов, разберёмся, в чём суть многопоточности, когда она полезна и как её реализовать — на примере Java. Если учите другой язык ООП, не огорчайтесь: базовые принципы одни и те же.
О потоках и их истоках
Чтобы понять многопоточность, сначала вникнем, что такое процесс. Процесс – это часть виртуальной памяти и ресурсов, которую ОС выделяет для выполнения программы. Если открыть несколько экземпляров одного приложения, под каждый система выделит по процессу. В современных браузерах за каждую вкладку может отвечать отдельный процесс.
Вы наверняка сталкивались с «Диспетчером задач» Windows (в Linux это — «Системный монитор») и знаете, что лишние запущенные процессы грузят систему, а самые «тяжёлые» из них часто зависают, так что их приходится завершать принудительно.
Но пользователи любят многозадачность: хлебом не корми — дай открыть с десяток окон и попрыгать туда-сюда. Налицо дилемма: нужно обеспечить одновременную работу приложений и при этом снизить нагрузку на систему, чтобы она не тормозила. Допустим, «железу» не угнаться за потребностями владельцев — нужно решать вопрос на программном уровне.
Мы хотим, чтобы в единицу времени процессор успевал выполнить больше команд и обработать больше данных. То есть нам надо уместить в каждом кванте времени больше выполненного кода. Представьте единицу выполнения кода в виде объекта — это и есть поток.
К сложному делу легче подступиться, если разбить его на несколько простых. Так и при работе с памятью: «тяжёлый» процесс делят на потоки, которые занимают меньше ресурсов и скорее доносят код до вычислителя (как именно — см. ниже).
У каждого приложения есть как минимум один процесс, а у каждого процесса — минимум один поток, который называют главным и из которого при необходимости запускают новые.
Разница между потоками и процессами
Потоки используют память, выделенную под процесс, а процессы требуют себе отдельное место в памяти. Поэтому потоки создаются и завершаются быстрее: системе не нужно каждый раз выделять им новое адресное пространство, а потом высвобождать его.
Процессы работают каждый со своими данными — обмениваться чем-то они могут только через механизм межпроцессного взаимодействия. Потоки обращаются к данным и ресурсам друг друга напрямую: что изменил один — сразу доступно всем. Поток может контролировать «собратьев» по процессу, в то время как процесс контролирует исключительно своих «дочек». Поэтому переключаться между потоками быстрее и коммуникация между ними организована проще.
Какой отсюда вывод? Если вам нужно как можно быстрее обработать большой объём данных, разбейте его на куски, которые можно обрабатывать отдельными потоками, а затем соберите результат воедино. Это лучше, чем плодить жадные до ресурсов процессы.
Но почему такое популярное приложение как Firefox идёт по пути создания нескольких процессов? Потому что именно для браузера изолированная работа вкладок — это надёжно и гибко. Если с одним процессом что-то не так, не обязательно завершать программу целиком — есть возможность сохранить хотя бы часть данных.
Что такое многопоточность
Вот мы и подошли к главному. Многопоточность — это когда процесс приложения разбит на потоки, которые параллельно — в одну единицу времени — обрабатываются процессором.
Вычислительная нагрузка распределяется между двумя или более ядрами, так что интерфейс и другие компоненты программы не замедляют работу друг друга.
Многопоточные приложения можно запускать и на одноядерных процессорах, но тогда потоки выполняются по очереди: первый поработал, его состояние сохранили — дали поработать второму, сохранили — вернулись к первому или запустили третий, и т.д.
Занятые люди жалуются, что у них всего две руки. Процессы и программы могут иметь столько рук, сколько нужно для скорейшего выполнения задачи.
Жди сигнала: синхронизация в многопоточных приложениях
Представьте, что несколько потоков пытаются одновременно изменить одну и ту же область данных. Чьи изменения будут в итоге приняты, а чьи — отменены? Чтобы работа с общими ресурсами не приводила к путанице, потокам нужно координировать свои действия. Для этого они обмениваются информацией с помощью сигналов. Каждый поток сообщает другим, что он сейчас делает и каких изменений ждать. Так данные всех потоков о текущем состоянии ресурсов синхронизируются.
В категориях объектно-ориентированного программирования сигналы — это объекты синхронизации. У каждого из них — своя роль во взаимодействии.
Основные средства синхронизации
Взаимоисключение (mutual exclusion, сокращённо — mutex) — «флажок», переходящий к потоку, который в данный момент имеет право работать с общими ресурсами. Исключает доступ остальных потоков к занятому участку памяти. Мьютексов в приложении может быть несколько, и они могут разделяться между процессами. Есть подвох: mutex заставляет приложение каждый раз обращаться к ядру операционной системы, что накладно.
Семафор — позволяет вам ограничить число потоков, имеющих доступ к ресурсу в конкретный момент. Так вы снизите нагрузку на процессор при выполнении кода, где есть узкие места. Проблема в том, что оптимальное число потоков зависит от машины пользователя.
Событие — вы определяете условие, при наступлении которого управление передаётся нужному потоку. Данными о событиях потоки обмениваются, чтобы развивать и логически продолжать действия друг друга. Один получил данные, другой проверил их корректность, третий — сохранил на жёсткий диск. События различаются по способу отмены сигнала о них. Если нужно уведомить о событии несколько потоков, для остановки сигнала придётся вручную ставить функцию отмены. Если же целевой поток только один, можно создать событие с автоматическим сбросом. Оно само остановит сигнал, после того как он дойдёт до потока. Для гибкого управления потоками события можно выстраивать в очередь.
Критическая секция — более сложный механизм, который объединяет в себе счётчик цикла и семафор. Счётчик позволяет отложить запуск семафора на нужное время. Преимущество в том, что ядро задействуется лишь в случае, если секция занята и нужно включать семафор. В остальное время поток выполняется в пользовательском режиме. Увы, секцию можно использовать только внутри одного процесса.
Как реализовать многопоточность в Java
За работу с потоками в Java отвечает класс Thread. Создать новый поток для выполнения задачи — значит создать экземпляр класса Thread и связать его с нужным кодом. Сделать это можно двумя путями:
образовать от Thread подкласс;
имплементировать в своём классе интерфейс Runnable, после чего передавать экземпляры класса в конструктор Thread.
Пока мы не будем затрагивать тему тупиковых ситуаций (deadlock’ов), когда потоки блокируют работу друг друга и зависают — оставим это для следующей статьи. А сейчас перейдём к практике.
Пример многопоточности в Java: пинг-понг мьютексами
Если вы думаете, что сейчас будет что-то страшное — выдохните. Работу с объектами синхронизации мы рассмотрим почти в игровой форме: два потока будут перебрасываться mutex’ом. Но по сути вы увидите реальное приложение, где в один момент времени только один поток может обрабатывать общедоступные данные.
Сначала создадим класс, наследующий свойства уже известного нам Thread, и напишем метод «удара по мячу» (kickBall):
Теперь позаботимся о мячике. Будет он у нас не простой, а памятливый: чтоб мог рассказать, кто по нему ударил, с какой стороны и сколько раз. Для этого используем mutex: он будет собирать информацию о работе каждого из потоков — это позволит изолированным потокам общаться друг с другом. После 15-го удара выведем мяч из игры, чтоб его сильно не травмировать.
А теперь на сцену выходят два потока-игрока. Назовём их, не мудрствуя лукаво, Пинг и Понг:
«Полный стадион народа — время начинать матч». Объявим об открытии встречи официально — в главном классе приложения:
Как видите, ничего зубодробительного здесь нет. Это пока только введение в многопоточность, но вы уже представляете, как это работает, и можете экспериментировать — ограничивать длительность игры не числом ударов, а по времени, например. Мы ещё вернёмся к теме многопоточности — рассмотрим пакет java.util.concurrent, библиотеку Akka и механизм volatile. А еще поговорим о реализации многопоточности на Python.
Какая тема вызывает больше всего вопросов и затруднений у начинающих? Когда я спросила об этом преподавателя и Java-программиста Александра Пряхина, он сразу ответил: «Многопоточность». Спасибо ему за идею и помощь в подготовке этой статьи!
Мы заглянем во внутренний мир приложения и его процессов, разберёмся, в чём суть многопоточности, когда она полезна и как её реализовать — на примере Java. Если учите другой язык ООП, не огорчайтесь: базовые принципы одни и те же.
О потоках и их истоках
Чтобы понять многопоточность, сначала вникнем, что такое процесс. Процесс – это часть виртуальной памяти и ресурсов, которую ОС выделяет для выполнения программы. Если открыть несколько экземпляров одного приложения, под каждый система выделит по процессу. В современных браузерах за каждую вкладку может отвечать отдельный процесс.
Вы наверняка сталкивались с «Диспетчером задач» Windows (в Linux это — «Системный монитор») и знаете, что лишние запущенные процессы грузят систему, а самые «тяжёлые» из них часто зависают, так что их приходится завершать принудительно.
Но пользователи любят многозадачность: хлебом не корми — дай открыть с десяток окон и попрыгать туда-сюда. Налицо дилемма: нужно обеспечить одновременную работу приложений и при этом снизить нагрузку на систему, чтобы она не тормозила. Допустим, «железу» не угнаться за потребностями владельцев — нужно решать вопрос на программном уровне.
Мы хотим, чтобы в единицу времени процессор успевал выполнить больше команд и обработать больше данных. То есть нам надо уместить в каждом кванте времени больше выполненного кода. Представьте единицу выполнения кода в виде объекта — это и есть поток.
К сложному делу легче подступиться, если разбить его на несколько простых. Так и при работе с памятью: «тяжёлый» процесс делят на потоки, которые занимают меньше ресурсов и скорее доносят код до вычислителя (как именно — см. ниже).
У каждого приложения есть как минимум один процесс, а у каждого процесса — минимум один поток, который называют главным и из которого при необходимости запускают новые.
Разница между потоками и процессами
Потоки используют память, выделенную под процесс, а процессы требуют себе отдельное место в памяти. Поэтому потоки создаются и завершаются быстрее: системе не нужно каждый раз выделять им новое адресное пространство, а потом высвобождать его.
Процессы работают каждый со своими данными — обмениваться чем-то они могут только через механизм межпроцессного взаимодействия. Потоки обращаются к данным и ресурсам друг друга напрямую: что изменил один — сразу доступно всем. Поток может контролировать «собратьев» по процессу, в то время как процесс контролирует исключительно своих «дочек». Поэтому переключаться между потоками быстрее и коммуникация между ними организована проще.
Какой отсюда вывод? Если вам нужно как можно быстрее обработать большой объём данных, разбейте его на куски, которые можно обрабатывать отдельными потоками, а затем соберите результат воедино. Это лучше, чем плодить жадные до ресурсов процессы.
Но почему такое популярное приложение как Firefox идёт по пути создания нескольких процессов? Потому что именно для браузера изолированная работа вкладок — это надёжно и гибко. Если с одним процессом что-то не так, не обязательно завершать программу целиком — есть возможность сохранить хотя бы часть данных.
Что такое многопоточность
Вот мы и подошли к главному. Многопоточность — это когда процесс приложения разбит на потоки, которые параллельно — в одну единицу времени — обрабатываются процессором.
Вычислительная нагрузка распределяется между двумя или более ядрами, так что интерфейс и другие компоненты программы не замедляют работу друг друга.
Многопоточные приложения можно запускать и на одноядерных процессорах, но тогда потоки выполняются по очереди: первый поработал, его состояние сохранили — дали поработать второму, сохранили — вернулись к первому или запустили третий, и т.д.
Занятые люди жалуются, что у них всего две руки. Процессы и программы могут иметь столько рук, сколько нужно для скорейшего выполнения задачи.
Жди сигнала: синхронизация в многопоточных приложениях
Представьте, что несколько потоков пытаются одновременно изменить одну и ту же область данных. Чьи изменения будут в итоге приняты, а чьи — отменены? Чтобы работа с общими ресурсами не приводила к путанице, потокам нужно координировать свои действия. Для этого они обмениваются информацией с помощью сигналов. Каждый поток сообщает другим, что он сейчас делает и каких изменений ждать. Так данные всех потоков о текущем состоянии ресурсов синхронизируются.
В категориях объектно-ориентированного программирования сигналы — это объекты синхронизации. У каждого из них — своя роль во взаимодействии.
Основные средства синхронизации
Взаимоисключение (mutual exclusion, сокращённо — mutex) — «флажок», переходящий к потоку, который в данный момент имеет право работать с общими ресурсами. Исключает доступ остальных потоков к занятому участку памяти. Мьютексов в приложении может быть несколько, и они могут разделяться между процессами. Есть подвох: mutex заставляет приложение каждый раз обращаться к ядру операционной системы, что накладно.
Семафор — позволяет вам ограничить число потоков, имеющих доступ к ресурсу в конкретный момент. Так вы снизите нагрузку на процессор при выполнении кода, где есть узкие места. Проблема в том, что оптимальное число потоков зависит от машины пользователя.
Событие — вы определяете условие, при наступлении которого управление передаётся нужному потоку. Данными о событиях потоки обмениваются, чтобы развивать и логически продолжать действия друг друга. Один получил данные, другой проверил их корректность, третий — сохранил на жёсткий диск. События различаются по способу отмены сигнала о них. Если нужно уведомить о событии несколько потоков, для остановки сигнала придётся вручную ставить функцию отмены. Если же целевой поток только один, можно создать событие с автоматическим сбросом. Оно само остановит сигнал, после того как он дойдёт до потока. Для гибкого управления потоками события можно выстраивать в очередь.
Критическая секция — более сложный механизм, который объединяет в себе счётчик цикла и семафор. Счётчик позволяет отложить запуск семафора на нужное время. Преимущество в том, что ядро задействуется лишь в случае, если секция занята и нужно включать семафор. В остальное время поток выполняется в пользовательском режиме. Увы, секцию можно использовать только внутри одного процесса.
Как реализовать многопоточность в Java
За работу с потоками в Java отвечает класс Thread. Создать новый поток для выполнения задачи — значит создать экземпляр класса Thread и связать его с нужным кодом. Сделать это можно двумя путями:
образовать от Thread подкласс;
имплементировать в своём классе интерфейс Runnable, после чего передавать экземпляры класса в конструктор Thread.
Пока мы не будем затрагивать тему тупиковых ситуаций (deadlock’ов), когда потоки блокируют работу друг друга и зависают — оставим это для следующей статьи. А сейчас перейдём к практике.
Пример многопоточности в Java: пинг-понг мьютексами
Если вы думаете, что сейчас будет что-то страшное — выдохните. Работу с объектами синхронизации мы рассмотрим почти в игровой форме: два потока будут перебрасываться mutex’ом. Но по сути вы увидите реальное приложение, где в один момент времени только один поток может обрабатывать общедоступные данные.
Сначала создадим класс, наследующий свойства уже известного нам Thread, и напишем метод «удара по мячу» (kickBall):
Теперь позаботимся о мячике. Будет он у нас не простой, а памятливый: чтоб мог рассказать, кто по нему ударил, с какой стороны и сколько раз. Для этого используем mutex: он будет собирать информацию о работе каждого из потоков — это позволит изолированным потокам общаться друг с другом. После 15-го удара выведем мяч из игры, чтоб его сильно не травмировать.
А теперь на сцену выходят два потока-игрока. Назовём их, не мудрствуя лукаво, Пинг и Понг:
«Полный стадион народа — время начинать матч». Объявим об открытии встречи официально — в главном классе приложения: