Поток выполнения
Пото́к выполне́ния (тред; от англ. thread — нить) — наименьшая единица обработки, исполнение которой может быть назначено ядром операционной системы. Реализация потоков выполнения и процессов в разных операционных системах отличается друг от друга, но в большинстве случаев поток выполнения находится внутри процесса. Несколько потоков выполнения могут существовать в рамках одного и того же процесса и совместно использовать ресурсы, такие как память, тогда как процессы не разделяют этих ресурсов. В частности, потоки выполнения разделяют последовательность инструкций процесса (его код) и его контекст — значения переменных (регистров процессора и стека вызовов), которые они имеют в любой момент времени.
В качестве аналогии потоки выполнения процесса можно уподобить нескольким вместе работающим поварам. Все они готовят одно блюдо, читают одну и ту же кулинарную книгу с одним и тем же рецептом и следуют его указаниям, причём не обязательно все они читают на одной и той же странице.
На одном процессоре многопоточность обычно происходит путём временного мультиплексирования (как и в случае многозадачности): процессор переключается между разными потоками выполнения. Это переключение контекста обычно происходит достаточно часто, чтобы пользователь воспринимал выполнение потоков или задач как одновременное. В многопроцессорных и многоядерных системах потоки или задачи могут реально выполняться одновременно, при этом каждый процессор или ядро обрабатывает отдельный поток или задачу.
Многие современные операционные системы поддерживают как временные нарезки от планировщика процессов, так и многопроцессорные потоки выполнения. Ядро операционной системы позволяет программистам управлять потоками выполнения через интерфейс системных вызовов. Некоторые реализации ядра называют потоком ядра, другие же — легковесным процессом (англ. light-weight process, LWP), представляющим собой особый тип потока выполнения ядра, который совместно использует одни и те же состояния и данные.
Программы могут иметь пользовательское пространство потоков выполнения при создании потоков с помощью таймеров, сигналов или другими методами, позволяющими прервать выполнение и создать временную нарезку для конкретной ситуации (Ad hoc).
Отличие от процессов
Потоки выполнения отличаются от традиционных процессов многозадачной операционной системы тем, что:
- процессы, как правило, независимы, тогда как потоки выполнения существуют как составные элементы процессов
- процессы несут значительно больше информации о состоянии, тогда как несколько потоков выполнения внутри процесса совместно используют информацию о состоянии, а также память и другие
- процессы имеют отдельные адресные пространства, тогда как потоки выполнения совместно используют их адресное пространство
- процессы взаимодействуют только через предоставляемые системой механизмы связей между процессами
- переключение контекста между потоками выполнения в одном процессе, как правило, быстрее, чем переключение контекста между процессами.
Такие системы, как Windows NT и OS/2, как говорят, имеют «дешёвые» потоки выполнения и «дорогие» процессы. В других операционных системах разница между потоками выполнения и процессами не так велика, за исключением расходов на переключение адресного пространства, которое подразумевает использование буфера ассоциативной трансляции.
Многопоточность
Многопоточность, как широко распространённая модель программирования и исполнения кода, позволяет нескольким потокам выполняться в рамках одного процесса. Эти потоки выполнения совместно используют ресурсы процесса, но могут работать и самостоятельно. Многопоточная модель программирования предоставляет разработчикам удобную абстракцию параллельного выполнения. Однако, пожалуй, наиболее интересное применение технологии имеется в том случае, когда она применяется к одному процессу, что позволяет его параллельное выполнение на многопроцессорной системе.
Это преимущество многопоточной программы позволяет ей работать быстрее на компьютерных системах, которые имеют несколько процессоров, процессор с несколькими ядрами или на кластере машин — из-за того, что потоки выполнения программ естественным образом поддаются действительно параллельному выполнению процессов. В этом случае программисту нужно быть очень осторожным, чтобы избежать состояния гонки, и другого неинтуитивного поведения. Для того, чтобы правильно манипулировать данными, потоки выполнения должны часто проходить через процедуру рандеву, чтобы обрабатывать данные в правильном порядке. Потокам выполнения могут также потребоваться мьютексы (которые часто реализуются с использованием семафоров), чтобы предотвратить одновременное изменение общих данных или их чтение во время процесса изменения. Неосторожное использование таких примитивов может привести к тупиковой ситуации.
Другим использованием многопоточности, применяемым даже для однопроцессорных систем, является возможность для приложения реагирования на ввод данных. В однопоточных программах, если основной поток выполнения заблокирован выполнением длительной задачи, всё приложение может оказаться в замороженном состоянии. Перемещая такие длительные задачи в рабочий поток, который выполняется параллельно с основным потоком, становится возможным для приложений продолжать реагировать на действия пользователя во время выполнения задач в фоновом режиме. С другой стороны, в большинстве случаев многопоточность — не единственный способ сохранить чувствительность программы. То же самое может быть достигнуто через асинхронный ввод-вывод или сигналы в UNIX.
Операционные системы планируют выполнение потоков одним из двух способов:
- Приоритетная многопоточность, вообще говоря, считается более совершенным подходом, так как она позволяет операционной системе определить, когда должно происходить переключение контекста. Недостаток приоритетной многопоточности состоит в том, что система может сделать переключение контекста в неподходящее время, что приводит к инверсии приоритета и другим негативным эффектам, которых можно избежать, применяя кооперативную многопоточность.
- Кооперативная многопоточность полагается на сами потоки и отказывается от управления, если потоки выполнения находятся в точках остановки. Это может создать проблемы, если поток выполнения ожидает ресурс, пока он не станет доступным.
До конца 1990-х процессоры в настольных компьютерах не имели поддержки многопоточности, так как переключение между потоками, как правило, происходило медленнее, чем полное переключение контекста процесса. Процессоры во встраиваемых системах, которые имеют более высокие требования к поведению в реальном времени, могут поддерживать многопоточность за счёт уменьшения времени на переключение между потоками, возможно, путём распределения выделенных регистровых файлов для каждого потока выполнения, вместо сохранения/восстановления общего регистрового файла. В конце 1990-х идея выполнения инструкций нескольких потоков одновременно, известная как одновременная многопоточность, под названием Hyper-Threading, достигла настольных компьютеров с процессором Intel Pentium 4. Потом она была исключена из процессоров архитектуры Intel Core и Core 2, но позже восстановлена в архитектуре Core i7.
Критики многопоточности утверждают, что увеличение использования потоков имеет существенные недостатки:
Хотя кажется, что потоки выполнения — это небольшой шаг от последовательных вычислений, по сути они представляют собой огромный скачок. Они отказываются от наиболее важных и привлекательных свойств последовательных вычислений: понятности, предсказуемости и детерминизма. Потоки выполнения, как модель вычислений, являются потрясающе недетерминированными, и уменьшение этого недетерминизма становится задачей программиста.
Процессы, потоки выполнения ядра, пользовательские потоки и файберы
Процесс является «самой тяжёлой» единицей планирования ядра. Собственные ресурсы для процесса выделяются операционной системой. Ресурсы включают память, дескрипторы файлов, разъёмы, дескрипторы устройств и окна. Процессы используют адресное пространство и файлы ресурсов в режиме разделения времени только через явные методы, такие как наследование дескрипторов файлов и сегментов разделяемой памяти. Процессы, как правило, предварительно преобразованы к многозадачному способу выполнения.
Потоки выполнения ядра относятся к «лёгким» единицам планирования ядра. Внутри каждого процесса существует по крайней мере один поток выполнения ядра. Если в рамках процесса могут существовать несколько потоков выполнения ядра, то они совместно используют общую память и файл ресурсов. Если процесс выполнения планировщика операционной системы является приоритетным, то потоки выполнения ядра тоже являются приоритетно многозадачными. Потоки выполнения ядра не имеют собственных ресурсов, за исключением стека вызовов, копии регистров процессора, включая счётчик команд, и локальную память потока выполнения (если она есть). Ядро может назначить по одному потоку выполнения для каждого логического ядра системы (поскольку каждый процессор разделяет сам себя на несколько логических ядер, если он поддерживает многопоточность, либо поддерживает только одно логическое ядро на каждое физическое ядро, если не поддерживает многопоточность), а может выполнять свопинг заблокированных потоков выполнения. Однако потоки выполнения ядра требуют гораздо больше времени, чем требуется на свопинг пользовательских потоков выполнения.
Потоки выполнения иногда реализуются в пользовательском пространстве библиотек, в этом случае они называются пользовательскими потоками выполнения. Ядро не знает о них, так что они управляются и планируются в пользовательском пространстве. В некоторых реализациях пользовательские потоки выполнения основываются на нескольких верхних потоках выполнения ядра, чтобы использовать преимущества многопроцессорных машин (модели M:N). В данной статье под термином «поток выполнения» по умолчанию (без квалификатора «ядра» или «пользовательский») имеется в виду «поток выполнения ядра». Пользовательские потоки выполнения, реализованные с помощью виртуальных машин, называют также «зелёными потоками выполнения». Пользовательские потоки выполнения, как правило, можно быстро создавать, и ими легко управлять, но они не могут использовать преимущества многопоточности и многопроцессорности. Они могут блокироваться, если все связанные с ним потоки выполнения ядра заняты, даже если некоторые пользовательские потоки готовы к запуску.
являются ещё более «лёгкими» блоками планирования, относящимися к кооперативной многозадачности: выполняющийся файбер должен явно «уступить» право другим файберам на выполнение, что делает их реализацию гораздо легче, чем реализацию потоков выполнения ядра или пользовательских потоков выполнения. Файберы могут быть запланированы для запуска в любом потоке выполнения внутри того же процесса. Это позволяет приложениям получить повышение производительности за счет управления планированием самого себя, вместо того чтобы полагаться на планировщик ядра (который может быть не настроен на такое применение). Параллельные среды программирования, такие как OpenMP, обычно реализуют свои задачи посредством файберов.
Проблемы потоков выполнения и файберов
Параллелизм и структуры данных
Потоки выполнения одного и того же процесса совместно используют одно и то же адресное пространство. Это позволяет одновременно выполняющимся кодам быть плотно связанными и удобно обмениваться данными без накладных расходов и сложности межпроцессного взаимодействия. При совместном доступе нескольких потоков даже к простым структурам данных возникает опасность возникновения состояния гонки в том случае, если для обновления данных требуется более одной инструкции процессора: два потока выполнения могут в конечном итоге попытаться одновременно обновить структуры данных и получить в итоге данные, состояние которых отличается от ожидаемого. Ошибки, вызванные состоянием гонки, бывает очень трудно воспроизвести и изолировать.
Чтобы избежать этого, прикладные программные интерфейсы (API) потоков выполнения предлагают , такие как мьютексы, для блокировки структур данных от одновременного доступа. На однопроцессорных системах поток выполнения, обратившийся к заблокированному мьютексу, должен остановить работу и, следовательно, инициировать переключение контекста. На многопроцессорных системах поток выполнения может вместо опроса мьютекса произвести захват спинлока. Оба этих способа могут снижать производительность и вынуждать процессор в SMP-системах конкурировать за шину памяти, особенно если блокировок слишком высокий.
Ввод-вывод и планирование
Реализация пользовательских потоков выполнения и файберов, как правило, производится полностью в пользовательском пространстве. В результате переключение контекста между пользовательскими потоками выполнения и файберами в одном и том же процессе очень эффективно, поскольку вообще не требует никакого взаимодействия с ядром. Переключение контекста производится локально путём сохранения регистров процессора, используемых работающим пользовательским потоком выполнения или файбером, и затем загрузкой регистров, требуемых для нового выполнения. Поскольку планирование происходит в пользовательском пространстве, политика планирования может быть легко адаптирована к требованиям конкретной программы.
Однако использование блокировок системных вызовов для пользовательских потоков выполнения (в отличие от потоков выполнения ядра) и файберов имеет свои проблемы. Если пользовательский поток выполнения или файбер выполняет системный вызов, другие потоки выполнения и файберы процесса не могут работать до завершения этой обработки. Типичный пример такой проблемы связан с выполнением операций ввода-вывода. Большинство программ рассчитаны на синхронное выполнение ввода-вывода. При инициации ввода-вывода делается системный вызов, и он не возвращается до его завершения. В промежутке весь процесс блокируется ядром и не может исполняться, лишая возможности работы другие пользовательские потоки и файберы этого процесса.
Общим решением этой проблемы является обеспечение отдельного API для ввода-вывода, который реализует синхронный интерфейс с использованием внутреннего неблокирующего ввода-вывода, и запуск другого пользовательского потока выполнения или файбера на время обработки ввода-вывода. Подобные решения могут быть предусмотрены для блокирующих системных вызовов. Кроме того, программа может быть написана так, чтобы избежать использования синхронного ввода-вывода или других блокирующих системных вызовов.
В SunOS 4.x реализованы так называемые «легковесные процессы» или LWP. В NetBSD 2.x + и DragonFly BSD реализованы LWP как потоки выполнения ядра (модель 1:1). В SunOS 5.2 и до SunOS 5.8, а также в NetBSD 2 и до NetBSD 4 реализована двухуровневая модель, использующая один или несколько пользовательских потоков выполнения на каждый поток выполнения ядра (модель M:N). В SunOS 5.9 и последующих версиях, а также в NetBSD 5 ликвидирована поддержка пользовательских потоков выполнения, произошёл возврат к модели 1:1. В FreeBSD 5 реализована модель M:N. В FreeBSD 6 поддерживаются обе модели: 1:1 и M:N, и пользователь может выбрать, какую из них он будет использовать в данной программе, используя /etc/libmap.conf. В FreeBSD начиная с версии 7 модель 1:1 стала использоваться по умолчанию, а в FreeBSD 8 и последующих версиях модель M:N не поддерживается совсем.
Использование потоков выполнения ядра упрощает код пользователя, перемещая некоторые из наиболее сложных аспектов многопотоковости в ядро. От программы не требуется планирование потоков выполнения и явных захватов процессора. Пользовательский код может быть записан в привычном процедурном стиле, включая вызовы блокирующего API без лишения доступа к процессору других потоков выполнения. Тем не менее, потоки выполнения ядра могут вызвать переключение контекста между потоками выполнения в любое время и тем самым подвергнуть опасности появления ошибок гонки и одновременности, которые могли бы не возникать. На SMP-системах это ещё более усугубляется, потому как потоки выполнения ядра могут в прямом смысле выполняться одновременно на разных процессорах.
Модели
1:1 (потоки выполнения на уровне ядра)
Потоки выполнения, созданные пользователем в модели 1-1, соответствуют диспетчируемым сущностям ядра. Это простейший возможный вариант реализации потоковости. В Windows API этот подход использовался с самого начала. В Linux обычная библиотека C реализует этот подход (через библиотеку потоков POSIX, а в более старших версиях — через LinuxThreads). Такой же подход используется ОС Solaris, NetBSD и FreeBSD.
N:1 (потоки выполнения уровня пользователя)
В модели N:1 предполагается, что все потоки выполнения уровня пользователя отображаются на единую планируемую сущность уровня ядра, и ядро ничего не знает о составе прикладных потоков выполнения. При таком подходе переключение контекста может быть сделано очень быстро, и, кроме того, он может быть реализован даже на простых ядрах, которые не поддерживают многопоточность. Однако, одним из главных недостатков его является то, что в нём нельзя извлечь никакой выгоды из аппаратного ускорения на многопоточных процессорах или многопроцессорных компьютерах, потому что только один поток выполнения может быть запланирован на любой момент времени. Эта модель используется в GNU Portable Threads.
M:N (смешанная потоковость)
В модели M:N некоторое число M прикладных потоков выполнения отображаются на некоторое число N сущностей ядра или «виртуальных процессоров». Модель является компромиссной между моделью уровня ядра («1:1») и моделью уровня пользователя («N:1»). Вообще говоря, «M:N» потоковость системы являются более сложной для реализации, чем ядро или пользовательские потоки выполнения, поскольку изменение кода как для ядра, так и для пользовательского пространства не требуется. В M:N реализации библиотека потоков отвечает за планирование пользовательских потоков выполнения на имеющихся планируемых сущностях. При этом переключение контекста потоков делается очень быстро, поскольку модель позволяет избежать системных вызовов. Тем не менее, увеличивается сложность и вероятность инверсии приоритетов, а также неоптимальность планирования без обширной (и дорогой) координации между пользовательским планировщиком и планировщиком ядра.
Реализации
Есть много различных, несовместимых друг с другом реализаций потоков. К ним относятся как реализации на уровне ядра, так и реализации на пользовательском уровне. Чаще всего они придерживаются более или менее близко стандарта интерфейса POSIX Threads.
Примеры реализаций потоков на уровне ядра
- Light Weight Kernel Threads (LWKT) в различных версиях BSD
- Потоковость MxN
- Библиотека потоков POSIX (NPTL) для Linux, реализация стандарта POSIX Threads
- Apple Multiprocessing Services, версия 2.0 и последующие, использует встроенное микроядро в Mac OS 8.6, в более поздних версиях сделана модификация с целью последующего сопровождения.
- Windows начиная с Windows 95, Windows NT и после них.
Примеры реализаций потоков на уровне пользователя
- GNU Portable Threads
- FSU Pthreads
- Thread Manager компании Apple
- REALbasic (включая API для совместного использования потоков)
- Netscape Portable Runtime (включая реализацию файберов в пользовательском пространстве)
Примеры реализаций смешанных потоков
- «Scheduler activations» используется в собственной библиотеке приложений потоков POSIX для NetBSD (модель M:N в противоположность модели 1:1 ядра или модели приложений пользовательского пространства)
- Marcel из проекта PM2
- ОС для суперкомпьютера Tera/Cray MTA
- Windows 7
Примеры реализаций файберов
Файберы могут быть реализованы без поддержки операционной системы, хотя некоторые операционные системы и библиотеки предоставляют явную поддержку для них.
- Библиотека Win32 содержит API для файберов (Windows NT 3.51 SP3 и выше)
- Ruby как реализация «зелёных потоков»
Поддержка языков программирования
Многие языки программирования поддерживают потоки по-разному. Большинство реализаций C и C++ (до стандарта C++11) само по себе не обеспечивает прямой поддержки потоков, но обеспечивает доступ к потокам, предоставляемым операционной системой, через API. Некоторые языки программирования более высокого уровня (как правило, кроссплатформенные), такие как Java, Python, и .NET, предоставляют управление потоками разработчику в виде абстрактной специфической платформы, отличающейся от реализации потоков в среде выполнения разработчика. Ряд других языков программирования также пытается полностью абстрагировать концепцию параллелизма и потоковости от разработчика (Cilk, OpenMP, MPI). Некоторые языки разрабатываются специально для параллелизма (Ateji PX, CUDA).
Некоторые интерпретирующие языки программирования, такие, как Руби и CPython (реализация Python на C), поддерживают потоки, но имеют ограничение, которое известно как глобальная блокировка интерпретатора (GIL). GIL является взаимной блокировкой исключений, выполняемых интерпретатором, которая может уберечь интерпретатор от одновременной интерпретации кода приложений в двух или более потоках одновременно, что фактически ограничивает параллелизм на многоядерных системах (в основном для потоков, связанных через процессор, а не для потоков, связанных через сеть).
См. также
- Поток данных
- Обмен сообщениями
- Thread-safety
- Неблокирующая синхронизация
Примечания
- Sergey Ignatchenko. Single-Threading: Back to the Future? Архивная копия от 29 сентября 2011 на Wayback Machine Overload #97
- Edward A. Lee. The Problem with Threads. Technical Report No. UCB/EECS-2006-1. EECS Department, University of California, Berkeley (10 января 2006). Дата обращения: 30 мая 2012. Архивировано 26 июня 2012 года.
- Oracle and Sun. Дата обращения: 30 ноября 2011. Архивировано из оригинала 27 марта 2009 года.
- CreateFiber Архивная копия от 17 июля 2011 на Wayback Machine MSDN
Литература
- David R. Butenhof. Programming with POSIX Threads. Addison-Wesley. ISBN 0-201-63392-2
- Bradford Nichols, Dick Buttlar, Jacqueline Proulx Farell. Pthreads Programming. O’Reilly & Associates. ISBN 1-56592-115-1
- Charles J. Northrup. Programming with UNIX Threads. John Wiley & Sons. ISBN 0-471-13751-0
- Mark Walmsley. Multi-Threaded Programming in C++. Springer. ISBN 1-85233-146-1
- Paul Hyde. Java Thread Programming. Sams. ISBN 0-672-31585-8
- Bill Lewis. Threads Primer: A Guide to Multithreaded Programming. Prentice Hall. ISBN 0-13-443698-9
- Steve Kleiman, Devang Shah, Bart Smaalders. Programming With Threads, SunSoft Press. ISBN 0-13-172389-8
- Pat Villani. Advanced WIN32 Programming: Files, Threads, and Process Synchronization. Harpercollins Publishers. ISBN 0-87930-563-0
- Jim Beveridge, Robert Wiener. Multithreading Applications in Win32. Addison-Wesley. ISBN 0-201-44234-5
- Thuan Q. Pham, Pankaj K. Garg. Multithreaded Programming with Windows NT. Prentice Hall. ISBN 0-13-120643-5
- Len Dorfman, Marc J. Neuberger. Effective Multithreading in OS/2. McGraw-Hill Osborne Media. ISBN 0-07-017841-0
- Alan Burns, Andy Wellings. Concurrency in ADA. Cambridge University Press. ISBN 0-521-62911-X
- Uresh Vahalia. Unix Internals: the New Frontiers. Prentice Hall. ISBN 0-13-101908-2
- Alan L. Dennis. .Net Multithreading. Manning Publications Company. ISBN 1-930110-54-5
- Tobin Titus, Fabio Claudio Ferracchiati, Srinivasa Sivakumar, Tejaswi Redkar, Sandra Gopikrishna. C# Threading Handbook. Peer Information. ISBN 1-86100-829-5
- Tobin Titus, Fabio Claudio Ferracchiati, Srinivasa Sivakumar, Tejaswi Redkar, Sandra Gopikrishna. Visual Basic .Net Threading Handbook. Wrox Press. ISBN 1-86100-713-2
Ссылки
- Answers to frequently asked questions for comp.programming.threads
- What makes multi-threaded programming hard?
- Binildas C. A. Query by Slice, Parallel Execute, and Join: A Thread Pool Pattern in Java
- Herb Sutter. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
- Concepts of Multithreading
- ConTest — A Tool for Testing Multithreaded Java Applications by IBM
- Debugging and Optimizing Multithreaded OpenMP Programs
- Multithreading в каталоге ссылок Curlie (dmoz)
- Multithreading in the Solaris Operating Environment Архивная копия от 27 марта 2009 на Wayback Machine
- Parallel computing community
- Daniel Robbins. POSIX threads explained
- The C10K problem
Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры, мобильный, телефон, Android, iOS, apple, мобильный телефон, Samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Сеть, компьютер, Информация о Поток выполнения, Что такое Поток выполнения? Что означает Поток выполнения?
Termin Potok imeet takzhe drugie znacheniya Termin Nit imeet takzhe drugie znacheniya Ne sleduet putat s Potok dannyh i Poryadok vypolneniya Poto k vypolne niya tred ot angl thread nit naimenshaya edinica obrabotki ispolnenie kotoroj mozhet byt naznacheno yadrom operacionnoj sistemy Realizaciya potokov vypolneniya i processov v raznyh operacionnyh sistemah otlichaetsya drug ot druga no v bolshinstve sluchaev potok vypolneniya nahoditsya vnutri processa Neskolko potokov vypolneniya mogut sushestvovat v ramkah odnogo i togo zhe processa i sovmestno ispolzovat resursy takie kak pamyat togda kak processy ne razdelyayut etih resursov V chastnosti potoki vypolneniya razdelyayut posledovatelnost instrukcij processa ego kod i ego kontekst znacheniya peremennyh registrov processora i steka vyzovov kotorye oni imeyut v lyuboj moment vremeni Process s dvumya potokami vypolneniya na odnom processore V kachestve analogii potoki vypolneniya processa mozhno upodobit neskolkim vmeste rabotayushim povaram Vse oni gotovyat odno blyudo chitayut odnu i tu zhe kulinarnuyu knigu s odnim i tem zhe receptom i sleduyut ego ukazaniyam prichyom ne obyazatelno vse oni chitayut na odnoj i toj zhe stranice Na odnom processore mnogopotochnost obychno proishodit putyom vremennogo multipleksirovaniya kak i v sluchae mnogozadachnosti processor pereklyuchaetsya mezhdu raznymi potokami vypolneniya Eto pereklyuchenie konteksta obychno proishodit dostatochno chasto chtoby polzovatel vosprinimal vypolnenie potokov ili zadach kak odnovremennoe V mnogoprocessornyh i mnogoyadernyh sistemah potoki ili zadachi mogut realno vypolnyatsya odnovremenno pri etom kazhdyj processor ili yadro obrabatyvaet otdelnyj potok ili zadachu Mnogie sovremennye operacionnye sistemy podderzhivayut kak vremennye narezki ot planirovshika processov tak i mnogoprocessornye potoki vypolneniya Yadro operacionnoj sistemy pozvolyaet programmistam upravlyat potokami vypolneniya cherez interfejs sistemnyh vyzovov Nekotorye realizacii yadra nazyvayut potokom yadra drugie zhe legkovesnym processom angl light weight process LWP predstavlyayushim soboj osobyj tip potoka vypolneniya yadra kotoryj sovmestno ispolzuet odni i te zhe sostoyaniya i dannye Programmy mogut imet polzovatelskoe prostranstvo potokov vypolneniya pri sozdanii potokov s pomoshyu tajmerov signalov ili drugimi metodami pozvolyayushimi prervat vypolnenie i sozdat vremennuyu narezku dlya konkretnoj situacii Ad hoc Otlichie ot processovPotoki vypolneniya otlichayutsya ot tradicionnyh processov mnogozadachnoj operacionnoj sistemy tem chto processy kak pravilo nezavisimy togda kak potoki vypolneniya sushestvuyut kak sostavnye elementy processov processy nesut znachitelno bolshe informacii o sostoyanii togda kak neskolko potokov vypolneniya vnutri processa sovmestno ispolzuyut informaciyu o sostoyanii a takzhe pamyat i drugie processy imeyut otdelnye adresnye prostranstva togda kak potoki vypolneniya sovmestno ispolzuyut ih adresnoe prostranstvo processy vzaimodejstvuyut tolko cherez predostavlyaemye sistemoj mehanizmy svyazej mezhdu processami pereklyuchenie konteksta mezhdu potokami vypolneniya v odnom processe kak pravilo bystree chem pereklyuchenie konteksta mezhdu processami Takie sistemy kak Windows NT i OS 2 kak govoryat imeyut deshyovye potoki vypolneniya i dorogie processy V drugih operacionnyh sistemah raznica mezhdu potokami vypolneniya i processami ne tak velika za isklyucheniem rashodov na pereklyuchenie adresnogo prostranstva kotoroe podrazumevaet ispolzovanie bufera associativnoj translyacii MnogopotochnostOsnovnaya statya Mnogopotochnost Mnogopotochnost kak shiroko rasprostranyonnaya model programmirovaniya i ispolneniya koda pozvolyaet neskolkim potokam vypolnyatsya v ramkah odnogo processa Eti potoki vypolneniya sovmestno ispolzuyut resursy processa no mogut rabotat i samostoyatelno Mnogopotochnaya model programmirovaniya predostavlyaet razrabotchikam udobnuyu abstrakciyu parallelnogo vypolneniya Odnako pozhaluj naibolee interesnoe primenenie tehnologii imeetsya v tom sluchae kogda ona primenyaetsya k odnomu processu chto pozvolyaet ego parallelnoe vypolnenie na mnogoprocessornoj sisteme Eto preimushestvo mnogopotochnoj programmy pozvolyaet ej rabotat bystree na kompyuternyh sistemah kotorye imeyut neskolko processorov processor s neskolkimi yadrami ili na klastere mashin iz za togo chto potoki vypolneniya programm estestvennym obrazom poddayutsya dejstvitelno parallelnomu vypolneniyu processov V etom sluchae programmistu nuzhno byt ochen ostorozhnym chtoby izbezhat sostoyaniya gonki i drugogo neintuitivnogo povedeniya Dlya togo chtoby pravilno manipulirovat dannymi potoki vypolneniya dolzhny chasto prohodit cherez proceduru randevu chtoby obrabatyvat dannye v pravilnom poryadke Potokam vypolneniya mogut takzhe potrebovatsya myuteksy kotorye chasto realizuyutsya s ispolzovaniem semaforov chtoby predotvratit odnovremennoe izmenenie obshih dannyh ili ih chtenie vo vremya processa izmeneniya Neostorozhnoe ispolzovanie takih primitivov mozhet privesti k tupikovoj situacii Drugim ispolzovaniem mnogopotochnosti primenyaemym dazhe dlya odnoprocessornyh sistem yavlyaetsya vozmozhnost dlya prilozheniya reagirovaniya na vvod dannyh V odnopotochnyh programmah esli osnovnoj potok vypolneniya zablokirovan vypolneniem dlitelnoj zadachi vsyo prilozhenie mozhet okazatsya v zamorozhennom sostoyanii Peremeshaya takie dlitelnye zadachi v rabochij potok kotoryj vypolnyaetsya parallelno s osnovnym potokom stanovitsya vozmozhnym dlya prilozhenij prodolzhat reagirovat na dejstviya polzovatelya vo vremya vypolneniya zadach v fonovom rezhime S drugoj storony v bolshinstve sluchaev mnogopotochnost ne edinstvennyj sposob sohranit chuvstvitelnost programmy To zhe samoe mozhet byt dostignuto cherez asinhronnyj vvod vyvod ili signaly v UNIX Operacionnye sistemy planiruyut vypolnenie potokov odnim iz dvuh sposobov Prioritetnaya mnogopotochnost voobshe govorya schitaetsya bolee sovershennym podhodom tak kak ona pozvolyaet operacionnoj sisteme opredelit kogda dolzhno proishodit pereklyuchenie konteksta Nedostatok prioritetnoj mnogopotochnosti sostoit v tom chto sistema mozhet sdelat pereklyuchenie konteksta v nepodhodyashee vremya chto privodit k inversii prioriteta i drugim negativnym effektam kotoryh mozhno izbezhat primenyaya kooperativnuyu mnogopotochnost Kooperativnaya mnogopotochnost polagaetsya na sami potoki i otkazyvaetsya ot upravleniya esli potoki vypolneniya nahodyatsya v tochkah ostanovki Eto mozhet sozdat problemy esli potok vypolneniya ozhidaet resurs poka on ne stanet dostupnym Do konca 1990 h processory v nastolnyh kompyuterah ne imeli podderzhki mnogopotochnosti tak kak pereklyuchenie mezhdu potokami kak pravilo proishodilo medlennee chem polnoe pereklyuchenie konteksta processa Processory vo vstraivaemyh sistemah kotorye imeyut bolee vysokie trebovaniya k povedeniyu v realnom vremeni mogut podderzhivat mnogopotochnost za schyot umensheniya vremeni na pereklyuchenie mezhdu potokami vozmozhno putyom raspredeleniya vydelennyh registrovyh fajlov dlya kazhdogo potoka vypolneniya vmesto sohraneniya vosstanovleniya obshego registrovogo fajla V konce 1990 h ideya vypolneniya instrukcij neskolkih potokov odnovremenno izvestnaya kak odnovremennaya mnogopotochnost pod nazvaniem Hyper Threading dostigla nastolnyh kompyuterov s processorom Intel Pentium 4 Potom ona byla isklyuchena iz processorov arhitektury Intel Core i Core 2 no pozzhe vosstanovlena v arhitekture Core i7 Kritiki mnogopotochnosti utverzhdayut chto uvelichenie ispolzovaniya potokov imeet sushestvennye nedostatki Hotya kazhetsya chto potoki vypolneniya eto nebolshoj shag ot posledovatelnyh vychislenij po suti oni predstavlyayut soboj ogromnyj skachok Oni otkazyvayutsya ot naibolee vazhnyh i privlekatelnyh svojstv posledovatelnyh vychislenij ponyatnosti predskazuemosti i determinizma Potoki vypolneniya kak model vychislenij yavlyayutsya potryasayushe nedeterminirovannymi i umenshenie etogo nedeterminizma stanovitsya zadachej programmista Processy potoki vypolneniya yadra polzovatelskie potoki i fajberyOsnovnaya statya Process informatika Process yavlyaetsya samoj tyazhyoloj edinicej planirovaniya yadra Sobstvennye resursy dlya processa vydelyayutsya operacionnoj sistemoj Resursy vklyuchayut pamyat deskriptory fajlov razyomy deskriptory ustrojstv i okna Processy ispolzuyut adresnoe prostranstvo i fajly resursov v rezhime razdeleniya vremeni tolko cherez yavnye metody takie kak nasledovanie deskriptorov fajlov i segmentov razdelyaemoj pamyati Processy kak pravilo predvaritelno preobrazovany k mnogozadachnomu sposobu vypolneniya Potoki vypolneniya yadra otnosyatsya k lyogkim edinicam planirovaniya yadra Vnutri kazhdogo processa sushestvuet po krajnej mere odin potok vypolneniya yadra Esli v ramkah processa mogut sushestvovat neskolko potokov vypolneniya yadra to oni sovmestno ispolzuyut obshuyu pamyat i fajl resursov Esli process vypolneniya planirovshika operacionnoj sistemy yavlyaetsya prioritetnym to potoki vypolneniya yadra tozhe yavlyayutsya prioritetno mnogozadachnymi Potoki vypolneniya yadra ne imeyut sobstvennyh resursov za isklyucheniem steka vyzovov kopii registrov processora vklyuchaya schyotchik komand i lokalnuyu pamyat potoka vypolneniya esli ona est Yadro mozhet naznachit po odnomu potoku vypolneniya dlya kazhdogo logicheskogo yadra sistemy poskolku kazhdyj processor razdelyaet sam sebya na neskolko logicheskih yader esli on podderzhivaet mnogopotochnost libo podderzhivaet tolko odno logicheskoe yadro na kazhdoe fizicheskoe yadro esli ne podderzhivaet mnogopotochnost a mozhet vypolnyat svoping zablokirovannyh potokov vypolneniya Odnako potoki vypolneniya yadra trebuyut gorazdo bolshe vremeni chem trebuetsya na svoping polzovatelskih potokov vypolneniya Potoki vypolneniya inogda realizuyutsya v polzovatelskom prostranstve bibliotek v etom sluchae oni nazyvayutsya polzovatelskimi potokami vypolneniya Yadro ne znaet o nih tak chto oni upravlyayutsya i planiruyutsya v polzovatelskom prostranstve V nekotoryh realizaciyah polzovatelskie potoki vypolneniya osnovyvayutsya na neskolkih verhnih potokah vypolneniya yadra chtoby ispolzovat preimushestva mnogoprocessornyh mashin modeli M N V dannoj state pod terminom potok vypolneniya po umolchaniyu bez kvalifikatora yadra ili polzovatelskij imeetsya v vidu potok vypolneniya yadra Polzovatelskie potoki vypolneniya realizovannye s pomoshyu virtualnyh mashin nazyvayut takzhe zelyonymi potokami vypolneniya Polzovatelskie potoki vypolneniya kak pravilo mozhno bystro sozdavat i imi legko upravlyat no oni ne mogut ispolzovat preimushestva mnogopotochnosti i mnogoprocessornosti Oni mogut blokirovatsya esli vse svyazannye s nim potoki vypolneniya yadra zanyaty dazhe esli nekotorye polzovatelskie potoki gotovy k zapusku yavlyayutsya eshyo bolee lyogkimi blokami planirovaniya otnosyashimisya k kooperativnoj mnogozadachnosti vypolnyayushijsya fajber dolzhen yavno ustupit pravo drugim fajberam na vypolnenie chto delaet ih realizaciyu gorazdo legche chem realizaciyu potokov vypolneniya yadra ili polzovatelskih potokov vypolneniya Fajbery mogut byt zaplanirovany dlya zapuska v lyubom potoke vypolneniya vnutri togo zhe processa Eto pozvolyaet prilozheniyam poluchit povyshenie proizvoditelnosti za schet upravleniya planirovaniem samogo sebya vmesto togo chtoby polagatsya na planirovshik yadra kotoryj mozhet byt ne nastroen na takoe primenenie Parallelnye sredy programmirovaniya takie kak OpenMP obychno realizuyut svoi zadachi posredstvom fajberov Problemy potokov vypolneniya i fajberov Parallelizm i struktury dannyh Potoki vypolneniya odnogo i togo zhe processa sovmestno ispolzuyut odno i to zhe adresnoe prostranstvo Eto pozvolyaet odnovremenno vypolnyayushimsya kodam byt plotno svyazannymi i udobno obmenivatsya dannymi bez nakladnyh rashodov i slozhnosti mezhprocessnogo vzaimodejstviya Pri sovmestnom dostupe neskolkih potokov dazhe k prostym strukturam dannyh voznikaet opasnost vozniknoveniya sostoyaniya gonki v tom sluchae esli dlya obnovleniya dannyh trebuetsya bolee odnoj instrukcii processora dva potoka vypolneniya mogut v konechnom itoge popytatsya odnovremenno obnovit struktury dannyh i poluchit v itoge dannye sostoyanie kotoryh otlichaetsya ot ozhidaemogo Oshibki vyzvannye sostoyaniem gonki byvaet ochen trudno vosproizvesti i izolirovat Chtoby izbezhat etogo prikladnye programmnye interfejsy API potokov vypolneniya predlagayut takie kak myuteksy dlya blokirovki struktur dannyh ot odnovremennogo dostupa Na odnoprocessornyh sistemah potok vypolneniya obrativshijsya k zablokirovannomu myuteksu dolzhen ostanovit rabotu i sledovatelno iniciirovat pereklyuchenie konteksta Na mnogoprocessornyh sistemah potok vypolneniya mozhet vmesto oprosa myuteksa proizvesti zahvat spinloka Oba etih sposoba mogut snizhat proizvoditelnost i vynuzhdat processor v SMP sistemah konkurirovat za shinu pamyati osobenno esli blokirovok slishkom vysokij Vvod vyvod i planirovanie Realizaciya polzovatelskih potokov vypolneniya i fajberov kak pravilo proizvoditsya polnostyu v polzovatelskom prostranstve V rezultate pereklyuchenie konteksta mezhdu polzovatelskimi potokami vypolneniya i fajberami v odnom i tom zhe processe ochen effektivno poskolku voobshe ne trebuet nikakogo vzaimodejstviya s yadrom Pereklyuchenie konteksta proizvoditsya lokalno putyom sohraneniya registrov processora ispolzuemyh rabotayushim polzovatelskim potokom vypolneniya ili fajberom i zatem zagruzkoj registrov trebuemyh dlya novogo vypolneniya Poskolku planirovanie proishodit v polzovatelskom prostranstve politika planirovaniya mozhet byt legko adaptirovana k trebovaniyam konkretnoj programmy Odnako ispolzovanie blokirovok sistemnyh vyzovov dlya polzovatelskih potokov vypolneniya v otlichie ot potokov vypolneniya yadra i fajberov imeet svoi problemy Esli polzovatelskij potok vypolneniya ili fajber vypolnyaet sistemnyj vyzov drugie potoki vypolneniya i fajbery processa ne mogut rabotat do zaversheniya etoj obrabotki Tipichnyj primer takoj problemy svyazan s vypolneniem operacij vvoda vyvoda Bolshinstvo programm rasschitany na sinhronnoe vypolnenie vvoda vyvoda Pri iniciacii vvoda vyvoda delaetsya sistemnyj vyzov i on ne vozvrashaetsya do ego zaversheniya V promezhutke ves process blokiruetsya yadrom i ne mozhet ispolnyatsya lishaya vozmozhnosti raboty drugie polzovatelskie potoki i fajbery etogo processa Obshim resheniem etoj problemy yavlyaetsya obespechenie otdelnogo API dlya vvoda vyvoda kotoryj realizuet sinhronnyj interfejs s ispolzovaniem vnutrennego neblokiruyushego vvoda vyvoda i zapusk drugogo polzovatelskogo potoka vypolneniya ili fajbera na vremya obrabotki vvoda vyvoda Podobnye resheniya mogut byt predusmotreny dlya blokiruyushih sistemnyh vyzovov Krome togo programma mozhet byt napisana tak chtoby izbezhat ispolzovaniya sinhronnogo vvoda vyvoda ili drugih blokiruyushih sistemnyh vyzovov V SunOS 4 x realizovany tak nazyvaemye legkovesnye processy ili LWP V NetBSD 2 x i DragonFly BSD realizovany LWP kak potoki vypolneniya yadra model 1 1 V SunOS 5 2 i do SunOS 5 8 a takzhe v NetBSD 2 i do NetBSD 4 realizovana dvuhurovnevaya model ispolzuyushaya odin ili neskolko polzovatelskih potokov vypolneniya na kazhdyj potok vypolneniya yadra model M N V SunOS 5 9 i posleduyushih versiyah a takzhe v NetBSD 5 likvidirovana podderzhka polzovatelskih potokov vypolneniya proizoshyol vozvrat k modeli 1 1 V FreeBSD 5 realizovana model M N V FreeBSD 6 podderzhivayutsya obe modeli 1 1 i M N i polzovatel mozhet vybrat kakuyu iz nih on budet ispolzovat v dannoj programme ispolzuya etc libmap conf V FreeBSD nachinaya s versii 7 model 1 1 stala ispolzovatsya po umolchaniyu a v FreeBSD 8 i posleduyushih versiyah model M N ne podderzhivaetsya sovsem Ispolzovanie potokov vypolneniya yadra uproshaet kod polzovatelya peremeshaya nekotorye iz naibolee slozhnyh aspektov mnogopotokovosti v yadro Ot programmy ne trebuetsya planirovanie potokov vypolneniya i yavnyh zahvatov processora Polzovatelskij kod mozhet byt zapisan v privychnom procedurnom stile vklyuchaya vyzovy blokiruyushego API bez lisheniya dostupa k processoru drugih potokov vypolneniya Tem ne menee potoki vypolneniya yadra mogut vyzvat pereklyuchenie konteksta mezhdu potokami vypolneniya v lyuboe vremya i tem samym podvergnut opasnosti poyavleniya oshibok gonki i odnovremennosti kotorye mogli by ne voznikat Na SMP sistemah eto eshyo bolee usugublyaetsya potomu kak potoki vypolneniya yadra mogut v pryamom smysle vypolnyatsya odnovremenno na raznyh processorah Modeli1 1 potoki vypolneniya na urovne yadra Potoki vypolneniya sozdannye polzovatelem v modeli 1 1 sootvetstvuyut dispetchiruemym sushnostyam yadra Eto prostejshij vozmozhnyj variant realizacii potokovosti V Windows API etot podhod ispolzovalsya s samogo nachala V Linux obychnaya biblioteka C realizuet etot podhod cherez biblioteku potokov POSIX a v bolee starshih versiyah cherez LinuxThreads Takoj zhe podhod ispolzuetsya OS Solaris NetBSD i FreeBSD N 1 potoki vypolneniya urovnya polzovatelya V modeli N 1 predpolagaetsya chto vse potoki vypolneniya urovnya polzovatelya otobrazhayutsya na edinuyu planiruemuyu sushnost urovnya yadra i yadro nichego ne znaet o sostave prikladnyh potokov vypolneniya Pri takom podhode pereklyuchenie konteksta mozhet byt sdelano ochen bystro i krome togo on mozhet byt realizovan dazhe na prostyh yadrah kotorye ne podderzhivayut mnogopotochnost Odnako odnim iz glavnyh nedostatkov ego yavlyaetsya to chto v nyom nelzya izvlech nikakoj vygody iz apparatnogo uskoreniya na mnogopotochnyh processorah ili mnogoprocessornyh kompyuterah potomu chto tolko odin potok vypolneniya mozhet byt zaplanirovan na lyuboj moment vremeni Eta model ispolzuetsya v GNU Portable Threads M N smeshannaya potokovost V modeli M N nekotoroe chislo M prikladnyh potokov vypolneniya otobrazhayutsya na nekotoroe chislo N sushnostej yadra ili virtualnyh processorov Model yavlyaetsya kompromissnoj mezhdu modelyu urovnya yadra 1 1 i modelyu urovnya polzovatelya N 1 Voobshe govorya M N potokovost sistemy yavlyayutsya bolee slozhnoj dlya realizacii chem yadro ili polzovatelskie potoki vypolneniya poskolku izmenenie koda kak dlya yadra tak i dlya polzovatelskogo prostranstva ne trebuetsya V M N realizacii biblioteka potokov otvechaet za planirovanie polzovatelskih potokov vypolneniya na imeyushihsya planiruemyh sushnostyah Pri etom pereklyuchenie konteksta potokov delaetsya ochen bystro poskolku model pozvolyaet izbezhat sistemnyh vyzovov Tem ne menee uvelichivaetsya slozhnost i veroyatnost inversii prioritetov a takzhe neoptimalnost planirovaniya bez obshirnoj i dorogoj koordinacii mezhdu polzovatelskim planirovshikom i planirovshikom yadra RealizaciiEst mnogo razlichnyh nesovmestimyh drug s drugom realizacij potokov K nim otnosyatsya kak realizacii na urovne yadra tak i realizacii na polzovatelskom urovne Chashe vsego oni priderzhivayutsya bolee ili menee blizko standarta interfejsa POSIX Threads Primery realizacij potokov na urovne yadra Light Weight Kernel Threads LWKT v razlichnyh versiyah BSD Potokovost MxN Biblioteka potokov POSIX NPTL dlya Linux realizaciya standarta POSIX Threads Apple Multiprocessing Services versiya 2 0 i posleduyushie ispolzuet vstroennoe mikroyadro v Mac OS 8 6 v bolee pozdnih versiyah sdelana modifikaciya s celyu posleduyushego soprovozhdeniya Windows nachinaya s Windows 95 Windows NT i posle nih Primery realizacij potokov na urovne polzovatelya GNU Portable Threads FSU Pthreads Thread Manager kompanii Apple REALbasic vklyuchaya API dlya sovmestnogo ispolzovaniya potokov Netscape Portable Runtime vklyuchaya realizaciyu fajberov v polzovatelskom prostranstve Primery realizacij smeshannyh potokov Scheduler activations ispolzuetsya v sobstvennoj biblioteke prilozhenij potokov POSIX dlya NetBSD model M N v protivopolozhnost modeli 1 1 yadra ili modeli prilozhenij polzovatelskogo prostranstva Marcel iz proekta PM2 OS dlya superkompyutera Tera Cray MTA Windows 7Primery realizacij fajberov Fajbery mogut byt realizovany bez podderzhki operacionnoj sistemy hotya nekotorye operacionnye sistemy i biblioteki predostavlyayut yavnuyu podderzhku dlya nih Biblioteka Win32 soderzhit API dlya fajberov Windows NT 3 51 SP3 i vyshe Ruby kak realizaciya zelyonyh potokov Podderzhka yazykov programmirovaniyaMnogie yazyki programmirovaniya podderzhivayut potoki po raznomu Bolshinstvo realizacij C i C do standarta C 11 samo po sebe ne obespechivaet pryamoj podderzhki potokov no obespechivaet dostup k potokam predostavlyaemym operacionnoj sistemoj cherez API Nekotorye yazyki programmirovaniya bolee vysokogo urovnya kak pravilo krossplatformennye takie kak Java Python i NET predostavlyayut upravlenie potokami razrabotchiku v vide abstraktnoj specificheskoj platformy otlichayushejsya ot realizacii potokov v srede vypolneniya razrabotchika Ryad drugih yazykov programmirovaniya takzhe pytaetsya polnostyu abstragirovat koncepciyu parallelizma i potokovosti ot razrabotchika Cilk OpenMP MPI Nekotorye yazyki razrabatyvayutsya specialno dlya parallelizma Ateji PX CUDA Nekotorye interpretiruyushie yazyki programmirovaniya takie kak Rubi i CPython realizaciya Python na C podderzhivayut potoki no imeyut ogranichenie kotoroe izvestno kak globalnaya blokirovka interpretatora GIL GIL yavlyaetsya vzaimnoj blokirovkoj isklyuchenij vypolnyaemyh interpretatorom kotoraya mozhet uberech interpretator ot odnovremennoj interpretacii koda prilozhenij v dvuh ili bolee potokah odnovremenno chto fakticheski ogranichivaet parallelizm na mnogoyadernyh sistemah v osnovnom dlya potokov svyazannyh cherez processor a ne dlya potokov svyazannyh cherez set Sm takzhePotok dannyh Obmen soobsheniyami Thread safety Neblokiruyushaya sinhronizaciyaPrimechaniyaSergey Ignatchenko Single Threading Back to the Future Arhivnaya kopiya ot 29 sentyabrya 2011 na Wayback Machine Overload 97 Edward A Lee The Problem with Threads neopr Technical Report No UCB EECS 2006 1 EECS Department University of California Berkeley 10 yanvarya 2006 Data obrasheniya 30 maya 2012 Arhivirovano 26 iyunya 2012 goda Oracle and Sun neopr Data obrasheniya 30 noyabrya 2011 Arhivirovano iz originala 27 marta 2009 goda CreateFiber Arhivnaya kopiya ot 17 iyulya 2011 na Wayback Machine MSDNLiteraturaDavid R Butenhof Programming with POSIX Threads Addison Wesley ISBN 0 201 63392 2 Bradford Nichols Dick Buttlar Jacqueline Proulx Farell Pthreads Programming O Reilly amp Associates ISBN 1 56592 115 1 Charles J Northrup Programming with UNIX Threads John Wiley amp Sons ISBN 0 471 13751 0 Mark Walmsley Multi Threaded Programming in C Springer ISBN 1 85233 146 1 Paul Hyde Java Thread Programming Sams ISBN 0 672 31585 8 Bill Lewis Threads Primer A Guide to Multithreaded Programming Prentice Hall ISBN 0 13 443698 9 Steve Kleiman Devang Shah Bart Smaalders Programming With Threads SunSoft Press ISBN 0 13 172389 8 Pat Villani Advanced WIN32 Programming Files Threads and Process Synchronization Harpercollins Publishers ISBN 0 87930 563 0 Jim Beveridge Robert Wiener Multithreading Applications in Win32 Addison Wesley ISBN 0 201 44234 5 Thuan Q Pham Pankaj K Garg Multithreaded Programming with Windows NT Prentice Hall ISBN 0 13 120643 5 Len Dorfman Marc J Neuberger Effective Multithreading in OS 2 McGraw Hill Osborne Media ISBN 0 07 017841 0 Alan Burns Andy Wellings Concurrency in ADA Cambridge University Press ISBN 0 521 62911 X Uresh Vahalia Unix Internals the New Frontiers Prentice Hall ISBN 0 13 101908 2 Alan L Dennis Net Multithreading Manning Publications Company ISBN 1 930110 54 5 Tobin Titus Fabio Claudio Ferracchiati Srinivasa Sivakumar Tejaswi Redkar Sandra Gopikrishna C Threading Handbook Peer Information ISBN 1 86100 829 5 Tobin Titus Fabio Claudio Ferracchiati Srinivasa Sivakumar Tejaswi Redkar Sandra Gopikrishna Visual Basic Net Threading Handbook Wrox Press ISBN 1 86100 713 2SsylkiAnswers to frequently asked questions for comp programming threads What makes multi threaded programming hard Binildas C A Query by Slice Parallel Execute and Join A Thread Pool Pattern in Java Herb Sutter The Free Lunch Is Over A Fundamental Turn Toward Concurrency in Software Concepts of Multithreading ConTest A Tool for Testing Multithreaded Java Applications by IBM Debugging and Optimizing Multithreaded OpenMP Programs Multithreading v kataloge ssylok Curlie dmoz Multithreading in the Solaris Operating Environment Arhivnaya kopiya ot 27 marta 2009 na Wayback Machine Parallel computing community Daniel Robbins POSIX threads explained The C10K problem
