Реферат: Теория многозадачности и многопоточности - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Теория многозадачности и многопоточности

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 338 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Введение К моменту появл ения персональных компьютеров в мире существ овало несколько технических решений позво ляющих реализовать многозадачность на больших машинах . В бывшем СССР это были машины серии ЕС и болгарские ИЗОТ . Они теоре тически позволяли подключать до 255 терминалов , где каждому терминалу выделялось некоторое к о личество ресурсов компьютера и п роцессорного времени . На практике нормальная работа такого комплекса обеспечивалась при на личии не более 25-30 терминалов , или меньше пр и сложных задачах . Для персональных ЭВМ многозадачность не вводилась принципиально . Вед ь исходя из названия PC – “ Personal Computer ” п редполагалось , что работать будет один челове к с одной текущей задачей . В качестве операционной системы была принята переработанная система CP / M под названи ем MS - DOS . Она так же не пред усматривала многозадачно сти . Основная проблем а разработки многозадачной операционной системы это не реентерабильность ее функций . То есть если один процесс запустил функцию чтения файла , то другой процесс не см ожет не только обращаться к файлам , но и вообще вызвать другие ее фун к ции . Для этого необходима поддержка на уровне процессора которая была введена с разработкой линейки 286. Многозадачность и многопоточность 1 Режим ы многозадачности 2 Многозадачность в DOS 2 Невытесняющая многозадачн ость 3 Presentation Manager и последовательная очередь сообщений 6 Р ешения , использующие многопоточность 7 Многопоточная архитектура 9 Коллизии , возникающие при использовании п отоков 10 Преимущества Windows 11 Новая усовершенствованная многопоточная прог рамма 13 О использовании функции Sleep 13 Критический раздел 14 Объект Mutex 17 Уведомления о событиях 18 Локальная память потока 18 Многозадачность и многопоточность Многозадачность ( multitasking ) – это с пособность операционной системы выполнять нескол ько программ одновременно . В основе этого прин ципа лежит использование операционной системой аппаратного таймера для выделения отрезков времени ( time slices ) для каждого из одновременно выполняемых проце ссов . Если эти отрезки времени достаточно малы , и машина не перегружена слишком боль шим числом прог рамм , то пользователю к ажется , что все эти программы выполняются параллельно. Идея многозадачности не нова . Многозадачн ость реализуется на больших компьютерах типа мэйнфрэйм ( mainframe ), к которым подключены десятки , а ино гда и сотни , терминалов . У каждого по льзователя , сидящего за экраном такого термин ала , создается впечатление , что он имеет э ксклюзивный доступ ко всей машине . Кроме т ого , операционные системы мэйнфрэймов часто д ают возможность пользователям перевести задачу в фоновый режим , где они выполн я ются в то время , как пользователь может работать с другой программой. Для того , чтобы многозадачность стала реальностью на персональных компьютерах , потребов алось достаточно много времени . Но , кажется , сейчас мы приближаемся к эпохе использован ия многозада чности на ПК ( PC ). Как мы увидим вскоре , некоторые расширенные 16-разрядные верс ии Windows поддержи вают многозадачность , а имеющиеся теперь в нашем распоряжении Windows NT и Windows 95 – 32-разрядные версии Windows , поддерживают кро ме многозадачности еще и многопоточность ( multithreading ). Многопоточность – это возможность программы самой бы ть многозадачной . Программа может быть раздел ена на отдельные потоки выполнения ( threads ), которые , как кажется , выполняются параллельно . На первый вз гляд эта концепция может показаться едв а ли полезной , но оказывается , что програм мы могут использовать многопоточность для вып олнения протяженных во времени операций в фоновом режиме , не вынуждая пользователя на долго отрываться от машины. Режимы многозадачности На заре использ ования персональных компьютеров некоторые отстаи вали идею многозадачности для будущего , но многие ломали головы над вопросом : какая польза от многозадачности на однопользовател ьской машине ? В действительности оказалос ь , что многозадачность – это именно то , что необходимо пользователям , даже не подозревавшим об э том. Многозадачность в DOS Микропроцессор Intel 8088, использовавшийся в первых ПК , не был специально разработан для реализации м ногозадачности . Частично проблема (как было по казано в предыдущей главе ) заключалась в н едостатках управления памятью . В то время , как множество программ начинает и зак анчивает свое выполнение , многозадачная о перационная система должна осуществлять перемеще ние блоков памяти для объединения свободного пространства . На процессоре 8088 это было невозможно р еализовать в стиле , прозрачном для приложений. Сама DOS не могла зде сь чем-либо существенно помочь . Будучи разработанной таким образом , чтобы быть маленькой и не мешать приложен иям , DOS поддержи вала , кроме загрузки программ и обеспечения им доступа к файловой системе , еще не так много средств. Тем не менее , творческие прог рамми сты , работавшие с DOS на заре ее появления , нашли пут ь преодоления этих препятствий , преимущественно при использовании резидентных ( terminate - and - stay - resident , TSR ) программ . Некоторые TSR-программы, такие как спу лер печати , использовали прерывание а ппар атного таймера для выполнения процесса в фоновом режиме . Другие , подобно всплывающим ( popup ) утилитам , так им как SideKick , могли выполнять одну из задач переключения – приостановк у выполнения приложения на время работы у тилиты . DOS также была усовершен ствована для обеспечения поддержки резидентных программ. Некоторые производители программного обеспеч ения пытались создать многозадачные оболочки или оболочки , использующие переключение между задачами , как надстройки над DOS (например , Quarterdeck ' s DeskVi ew ), но только одна из этих оболочек получила широкое распространение на рынке . Это , конечно . Windows . Невытесняющая многозадачность Когда Microsoft выпустила на рынок Windows 1.0 в 1985 году , это было еще в большо й степени искусственным решением , придуманным для преодоления ограничений MS DOS . В то время Windows работала в реальном режиме ( real mode ), но даже тогда она была способна перемещать блоки физич еской памяти (одно из необходимых услови й многозадачности ) и делала это , хотя и не очень прозрачно для приложений , но в се-таки вполне удовлетворительно. В графической оконной среде многозадачнос ть приобретает гораздо больший смысл , чем в однопользовательской операционной систем е , использующей командную строку . Например , в классической операционной системе UNIX , работающей с командной строкой , существует возможность запуска ть программы из командной строки так , чтоб ы они выполнялись в фоновом режиме . Однако , любой вывод на экран и з программ ы должен быть переадресован в файл , иначе этот вывод смешается с текущим содержимы м экрана. Оконная оболочка позволяет нескольким про граммам выполняться совместно , разделяя один экран . Переключение вперед и назад становится тривиальным , существуе т возможность быст ро передавать данные из одной программы в другую , например , разместить картинку , созданн ую в программе рисования , в текстовом файл е , образованном с помощью текстового процессо ра . Передача данных поддерживалась в различны х версиях Windows : сначала с использованием папки обмена ( clipboard ), позднее – посредством механизма динамического обмена данными ( Dynamic Data Exchange , DDE ), сейчас – через внедрение и связывание объектов ( Object Linking and Embedding , OLE ). И все же , реализованная в ран н их версиях Windows многозадачность не была традиционной в ытесняющей , основанной на выделении отрезков времени , как в многопользовательских операционных системах . Такие операционные системы использ уют системный таймер для периодического преры вания выполнен ия одной задачи и запус ка другой . 16-разрядные версии Windows поддерживали так называе мую невытесняющую многозадачность ( non - preemptive multitasking ). Так ой тип многозадачности был возможен благодаря основанной на сообщениях архитектуре Windows . В общем сл учае, Windows-программа находилась в памяти и не выполняла сь до тех пор , пока не получала сообще ние . Эти сообщения часто являлись прямым и ли косвенным результатом ввода информации пол ьзователем с клавиатуры или мыши . После об работки сообщения программа воз вращала уп равление обратно Windows . 16-разрядные версии Windows не имели возможности произвольн о переключать управление с одной Windows-программы на др угую , основываясь на квантах времени таймера . Переключение между задачами происходило в момент , когда про грамма завершала обраб отку сообщения и возвращала управление Windows . Такую невытесняю щую многозадачность называют также кооперативной многозадачностью ( cooperative multitasking ) потому , что она требует некоторого согласов ания между приложениями . Одна Wind ows-программа могла пар ализовать работу всей системы , если ей тре бовалось много времени для обработки сообщени я. Хотя невытесняющая многозадачность была о сновным типом многозадачности в 16-разрядных ве рсиях Windows , некот орые элементы вытесняющей (примитив ной , preemptive ) многозадачности в них тоже присутствовали. Windows использовала вытесняющую многозадачность для выполнения DOS-программ, а также позволяла библиотекам динамической компо новки ( DLL ) получ ать прерывания аппаратного таймера для задач мультиме диа. 16-разрядные версии Windows имели некоторые особенности , ко торые помогали программистам если не разрешит ь , то , по крайней мере , справиться с ог раничениями , связанными с невытесняющей многозада чностью . Наиболее известной является отображение курсора мы ши в виде песочных час ов . Конечно , это не решение проблемы , а только лишь возможность дать знать пользоват елю , что программа занята выполнением протяже нной во времени работы , и что система какое-то время будет недоступна . Другим частич ным решением являетс я использование системного таймера Windows , что позволяет выполнять какие-либо действия периодически . Таймер часто используется в приложениях типа часов и приложениях , работающих с анимацией. Другим решением по преодолению ограничени й невытесняющей многозад ачности является вызов функции PeekMessage , как мы видели в программе RANDRECT в глав е 4. Обычно пр ограмма использует вызов функции GetMes - sage для извлечения сообщений из очереди . Однако , если в данный момент вр емени очередь сообщений пуста , то функция Ge tMessage буд ет ждать поступления сообщения в очередь , а затем возвратит его . Функция PeekMessage раб отает иначе – она возвращает управление программе да же в том случае , если нет сообщений в очереди . Таким образом , выполнение работы , требующей больших затра т времени , будет продолжаться до того момента , пока в оч ереди не появятся сообщения для данной ил и любой другой программы. Presentation Manager и последовательная очередь сообщен ий Первой попыткой фирмы Microsoft (в сотрудничестве с IBM ) внедрить многозадачность в квази -DOS/Windows оболочку была система OS/2 и Presentation Manager ( PM ). Хотя OS/2, конечно , поддержив ала вытесняющую многозадачность , часто казалось , что это вытеснени е не было перенес ено в PM. Дело в том , что PM выстраивал в очередь сообщения , формиру емые в результате пользовательского ввода от клавиатуры или мыши . Это означает , что PM не предоставля ет программе такое пользовательское сообщение до тех пор , пока предыду щее сообщен ие , введенное пользователем , не будет полность ю обработано. Хотя сообщения от клавиатуры или мыши – это тол ько часть множества сообщений , которые может получить программа в PM или Windows , большинство других сообщений являются результатом событи й , связанных с клав иатурой или мышью . Например , сообщение от меню команд является результатом выбора пункт а меню с помощью клавиатуры или мыши . Сообщение от клавиатуры или мыши не будет обработано до тех пор , пока не будет полностью обработано сообщение о т меню. Основная причина организации последовательно й очереди сообщений состоит в том , чтобы отследить все действия пользователя . Если какое-либо сообщение от клавиатуры или мыши вызывает переход фокуса ввода от одного окна к другому , то следующее сообщение клавиатуры должно быть направлено в окно , на которое установился фокус ввода . Таким образом , система не знает , в какое окно передавать сообщение на обработку д о тех пор , пока не будет обработано пр едыдущее сообщение. В настоящее время принято соглашение о том , что не должно быть возможност и для какого-либо одного приложения парализов ать работу всей системы , и что требуется использовать непоследовательную очередь сообщен ий , поддерживаемую системами Windows 95 и Windows NT . Если одна прог рамма занята выполне нием протяженной во времени операции , то существует возможность переключить фокус ввода на другое прилож ение. Решения , использующие многопоточность Выше был рассмо трен Presentati on Manager опер ационной системы OS/2 только из-за того , что это была пер вая оболочка , которая подготовила сознание не которых ветеранов программирования под Windows (в том числе и автора ) к введению многопоточности . Инт ересно , что ограниченная поддержка мно гопоточности в РМ дала программистам основную идею организации программ , использующих многопоточность . Хотя эти ограничения сейчас преимущественно преодолены в Windows 95, тем не менее уроки , полученн ые при работе с более ограниченными систе мами , остаются актуальными и по сей день. В многопоточной среде программы могут быть разделены на части , называемые потокам и выполнения (threads), которые выполняются одновременно . Поддержка многопоточности оказывается лучшим решением проблемы последовательной очереди со общений в РМ и приобретает полный смысл при ее реализации в Windows 95. В терминах программы "поток " – это просто функция , которая может также вызывать другие функции программы . Программа начинает выполн яться со своего главного (первичного ) потока , который в традиционных программах на языке С является функцией main, а в Windows-программах – WinMain. Будуч и выполняемой , функция может создавать новые потоки обработки , выполняя системный вызов с указанием функции инициализации потока (initial threading functio n). Опе рационная система в вытесняющем режиме перекл ючает управление между потоками подобно тому , как она это делает с процессами. В РМ системы OS/2 любой поток может либо создавать очередь сообщений , либо не создавать . РМ-пот ок должен создавать очередь со общений , если он собирается создавать окно . С др угой стороны , поток может не создавать оче редь сообщений , если он осуществляет только обработку данных или графический вывод . Пос кольку потоки , не создающие очереди сообщений , не обрабатывают сообщения , то о н и не могут привести к "зависанию " с истемы . На поток , не имеющий очереди сообщ ений , накладывается только одно ограничение – он не мо жет посылать асинхронное сообщение в окно потока , имеющего очередь сообщений , или вызы вать какую-либо функцию , если это приве дет к посылке сообщения . (Однако эти потоки могут посылать синхронные сообщения потокам , имеющим о чередь сообщений .) Таким образом , программисты , работавшие с РМ , научились разбивать свои программы на один поток с очередью сообщений , создающи й все окна и о брабатывающий сообщения для них , и один или несколько потоков , не имеющих очередей сообщений , и выполня ющих продолжительные действия в фоновом режим е . Кроме того , программисты , работавшие с Р М , узнали о "правиле 1/10 секунды ". Оно состоит в том , ч то поток с очередью сообщений тратит не более 1/10 секунды на обработку любого сообщения . Все , что требует большего времени , следовало выд елять в отдельный поток . Если все программ исты придерживались этого правила , то никакая РМ-программа не могла вызвать зависание системы более чем на 1/10 секунды. Многопоточная архитектура Как уже отмечал ось выше , ограничения РМ дали программистам основные идеи для понимания того , как и спользовать множес тво потоков в программе , выполняемой в графической среде . Ниже пр иведены наши рекомендации по архитектуре мног опоточных программ : первичный или главный (primary) поток вашей программы создает все окна и соответствующ ие им оконные процедуры , необходимые в п рограмме и обрабатывает все сообщения для этих окон . Все остальные потоки – это просто фоновые задачи . Они не имеют интерактивной связи с пользователем , кроме как через первичный поток. Один из способов добиться этого состо ит в том , чтобы первичный поток о б рабатывал пользовательский ввод и другие сооб щения , возможно создавая при этом вторичные (secondary) потоки в процессе . Эти вторичные потоки выполняют не связанные с пользователем задачи. Другими словами , первичный поток вашей программы является губернато ром , а втор ичные потоки – свитой губернатора . Губернатор поручает всю большую работу своим помощникам на то время , пока он осуществляет контакты с внешним миром . Поскольку вторичные потоки являются членами свиты , они не могут пр оводить свои пресс-конференц ии . Они скромн о выполняют каждый свое задание , делают от чет губернатору и ждут новых указаний. Потоки внутри отдельной программы являютс я частями одного процесса , поэтому они раз деляют все ресурсы процесса , такие как пам ять и открытые файлы . Поскольку пото ки разделяют память , отведенную программе , то они разделяют и статические переменные . Одн ако , у каждого потока есть свой собственны й стек , и значит , автоматические переменные являются уникальными для каждого потока . Ка ждый поток , также , имеет свое состоян и е процессора , которое сохраняется и во сстанавливается при переключении между потоками. Коллизии , возникающие при использовании потоков Собственно разработ ка , программирование и о тладка сложного многопоточного приложения являются , естественно , самыми сложными задачами , с которыми приход ится сталкиваться программисту для Windows. Поскольку в системе с вытесняющей многозадачностью поток может быть прерван в любой момент для переключе ния на другой поток , то мо жет случайно произойти любое нежелательное вз аимодействие между двумя потоками. Одной из основных ошибок в многопоточ ных программах является так называемое состоя ние гонки (race condition). Это случается , если программист считает, что один поток закончит выполнение своих действий , например , подготовку каких-либо данных , до того , как эти данные потребую тся другому потоку . Для координации действий потоков операционным системам необходимы раз личные формы синхронизации . Одной из таких форм является семафор (semaphore), который позволяет прогр аммисту приостановить выполнение потока в кон кретной точке программы до тех пор , пока он не получит от другого потока сигн ал о том , что он может возобновить раб оту . Похожи на семафоры критические ра зделы (critical sections), кото рые представляют собой разделы кода , во вр емя выполнения которого , поток не может бы ть прерван. Но использование семафоров может привести к другой распространенной ошибке , связанной с потоками , которая называется тупиком (dea dlock). Это случается , когда два потока блокируют выполне ние друг друга , а для того , чтобы их разблокировать необходимо продолжить работу. К счастью , 32-разрядные программы более устойчивы к определенным проблемам , включая п роблемы с потоками , чем 16-разря дные про граммы . Например , предположим , что один поток выполняет простое действие : lCount++ ; где ICount – 32-разрядная глобальная переменная типа длинное целое , используемая другими потоками . В 16-разрядной программе , в которой такой оператор языка С транс лируется в две инструкции машинного к ода (сначала инкрементируется младшие 16 разрядов , а зат ем добавляется перенос в старшие 16 разрядов ). Допустим , что операционная система прервала поток между этими двумя инструкциями машинного кода . Если переменная ICo unt имела зна чение $0000FFFF, то после выполнения первой инструкции машинного кода ICount будет иметь нулевое значение . Е сли в этот момент произойдет прерывание п отока , то другой поток получит нулевое зна чение переменной ICount. Только после окончания этог о п отока значение ICount будет увеличено на единицу до своего истинного значения $00010000. Такого рода ошибка может быть никогда не выявлена , поскольку довольно редко при водит к проблемам во время выполнения . Для 16-разрядных программ наилучший путь предо твратить такую ошибку – это поместить данное выраж ение в критический раздел , в рамках которо го поток не может быть прерван . В 32-раз рядной программе , однако , приведенное выражение является абсолютно корректным , поскольку оно компилируется в одну инструкцию машинног о кода. Преимущества Windows Операционные систем ы Windows 95 и Windows NT не имеют последовательной очереди сооб щений . Такое решение кажется очень хорошим : если программ а выполняет длительную об работку сообщения , то курсор мыши принимает форму песочных часов при расположении над окном этой программы , и изменяется на обычную стрелку , если он располагается над окном другой программы . Простым щелчком к нопкой мыши можно пере в ести друго е окно на передний план. Однако , пользователь по-прежнему не может работать с приложением , выполняющим длительн ую операцию , поскольку выполнение длительной операции предотвращает получение сообщений прогр аммой . А это нежелательно . Программа должн а быть всегда открыта для сообщений , а это требует использования вторичных пото ков. В Windows 95 и Windows NT не существует различия между потоками , имеющими очередь сообщений , и пото ками без очереди сообщений . При создании к аждый поток получает свою собст венную очередь сообщений . Это снижает число ограни чений , существующих для потоков в РМ-программе . (Однако , в большинстве случаев все еще обработка ввода и сообщений осуществляется в одном потоке , а протяженные во времен и задачи передаются другим потокам , к оторые не создают окон .) Такая схема организации приложения , как мы увидим , почти всегда является наиболее разумной. В Windows 95 и Windows NT есть функция , которая позволяет одному потоку уничтожить другой поток , пр инадлежащий тому же процессу . Как вы обн аружите , когда начнете писать многопоточн ые приложения под Windows, иногда это очень удобно . Ранние версии операционной системы OS/2 не содержали функции для уничтожения потоков. Windows 95 и Windows NT поддерживают так называемую локальную память потока ( thread local storage, TLS). Для того чтобы понять , что э то такое , вспомним о том , что статические переменные , как глобальные так и локальны е по отношению к функциям , разделяются меж ду потоками , поскольку они расположены в з оне памяти данных процесса . Автом атически е переменные (которые являются всегда локальн ыми по отношению к функции ) – уникальны для каждого потока , т . к . они располагаются в стек е , а каждый поток имеет свой стек. Иногда бывает удобно использовать для двух и более потоков одну и ту же функци ю , а статические данные использ овать уникальные для каждого потока . Это и есть пример использования локальной памяти потока . Существует несколько вызовов функций Windows для работ ы с локальной памятью потока . Фирма Microsoft ввела расширение в компилятор С, которое позволяет использовать локальную память потока более прозрачным для програм миста образом. Новая усовершенствованная многопоточная программа Иногда имеет ме сто тенденция использовать в программе каждую возможность , предлагаемую операционной сис темой . Нет смысла использовать множество пото ков в программе , которая в этом не нуж дается . Если программа выводит на экран ку рсор в виде песочных часов на достаточно долгий период в ремени , или , если она использует функцию PeekMessage для тог о , чтобы избежать появления курсора в виде песочных часов , то тогда идея реструктури зации программы в многопоточную , вероятно , мож ет оказаться хорошей . В противном случае , вы только усложните себе работу и , в озможно , внесете в программу новые ошибки. Есть даже некоторые ситуации , когда по явление курсора мыши в виде песочных часо в , может быть совершенно подходящим . Выше уже упоминалось "правило 1/10 секунды ". Так вот , загрузка больш ого файла в памят ь может потребовать больше времени , чем 1/10 секунды . Значит ли это , что ф ункции загрузки файла должны были быть ре ализованы с использованием разделения на пото ки ? Совсем необязательно . Когда пользователь д ает программе команду открыть файл , то он или она обычно хочет , чтобы операци онная система выполнила ее немедленно . Выделе ние процесса загрузки файла в отдельный п оток просто приведет к усложнению программы . Не стоит это делать даже ради того , чтобы похвастаться перед друзьями , что вы пишите многопоточны е приложения. О использовании функции Sleep Выше было показ ано , как лучше организовать архитектуру прогр аммы , использующей многопоточность , а именно , ч тобы первичный поток создава л все окн а в программе , содержал все оконные процед уры этих окон и обрабатывал все сообщения . Вторичные потоки выполняют фоновые задачи или задачи , протяженные во времени. Однако , предположим , что требуется реализо вать анимацию во вторичном потоке . Обычно анимация в Windows осуществляется с использованием сообщения WM_TIMER. Но если вторичный поток не создает окно , то о н не может получить это сообщение . А б ез задания определенного темпа анимация могла бы осуществляться слишком быстро. Решение состоит в испо льзовании ф ункции Sleep. Поток вызывает функцию Sleep для того , что бы добровольно отложить свое выполнение . Един ственный параметр этой функции – время , задаваемое в миллисекундах . Функция Sleep не осуществляет возврата до тех пор , пока не истечет указанное время . В течение него вып олнение потока приостанавливается и выделения для него процессорного времени не происход ит (хотя очевидно , что для потока все-таки требуется какое-то незначительное время , за которое система должна определить , пора воз обновлять в ы полнение потока или н ет ). Если параметр функции Sleep задан ра вным нулю , то поток будет лишен остатка выделенного ему кванта процессорного времени. Когда поток вызывает функцию Sleep, задержка на заданное время относится к этому потоку . Система продолжает вы полнять другие потоки этого и других проц ессов Критический раздел В однозадачной операционной системе обычные программы не нуж даются в "светофорах " для координации их д ействий . Они выполняются так , как будто они являются хозяевами дороги , по которой они следуют . Не существует ничего , что могло бы вмешаться в то , что они де лают. Даже в многозадачной операционной системе большинство программ выполняются независимо друг от друга . Но некоторые проблемы все же могут возникнуть . Например , двум программам может понадобиться читать и писать в один файл в одно и то же вр емя . Для таких случаев операционная система поддерживает механизм разделения файлов (shared files) и блокирования отдел ьных фрагментов файла (record locking). Однако , в операционной системе , поддержива ющей многопоточность , такое решение может вне сти путаницу и создать потенциальную опасност ь . Разделение данных между двумя и более потоками является общим случаем . Например , один поток может обновлять одну или более п еременных , а другой может использовать эти переменные . Иногда в этой ситуации может возникнуть проблема , а иногда – нет . (Помните , что о перационная система может переключать управление потоками только между инстру кциями м ашинного кода . Если простое целое число ра зделяется между двумя потоками , то изменение этой переменной обычно осуществляется одной инструкцией машинного кода , и потенциальные проблемы сводятся к минимуму .) Однако , предположим , что потоки разделяют несколько переменных или структуру дан ных . Часто эти сложные переменные или поля структур данных должны быть согласованными между собой . Операционная система может п рерывать поток в середине процесса обновления этих переменных . В этом случае поток , которы й затем использует эти переме нные , будет иметь дело с несогласованными данными. В результате бы возникла коллизия , и нетрудно представить себе , как такого род а ошибка может привести к краху программы . В этой ситуации нам необходимо нечто похожее на светофор , который мог бы синхронизировать и координировать работу поток ов . Таким средством и является критический раздел . Критический раздел – это блок кода , при выпо лнении которого поток не может быть прерв ан. Имеется четыре функции для работы с критическими разд елами . Чтобы их исполь зовать , вам необходимо определить объект типа критический раздел , который является глобаль ной переменной типа CRITICAL_SECTION. Например, CRITICAL_SECTION CS ; Тип данных CRITICAL_SECTION является струк турой , но ее поля используются т олько внутри Windows. О бъект типа критический раздел сначала должен быть инициализирован одним из потоков пр ограммы с помощью функции : InitializeCriticalSection (&cs); Эта функция соз дает объект критический раздел с именем cs. В документации содержится сле дующе е предупреждение : "Объект критический раздел н е может быть перемещен или скопирован . Про цесс также не должен модифицировать объект , а должен обращаться с ним , как с "че рным ящиком ". " После инициализации объекта критический р аздел поток входит в критич еский разд ел , вызывая функцию : EnterCriticalSection (&cs) ; В этот момент поток становится владельцем объекта . Два ра зличных потока не могут быть владельцами одного объекта критический раздел одновременно . Следовательно , если один поток вошел в критический раздел , то следующий поток , в ызывая функцию EnterCriticalSection с тем же самым объектом критический раздел , будет задержан внутри функции . Возврат из функции произойдет то лько тогда , когда первый поток покинет кри тический раздел , вызвав функцию : LeaveCri ticalSection (&cs); В этот момент второй поток , задержанный в функции EnterCriticalSection, станет владельцем критического раздела , и его выполнение будет возобновлено. Когда объект критический раздел больше не нужен вашей программе , его можно уда лить с по мощью функции : DeleteCriticalSection (&cs); Это приведет к освобождению всех ресурсов системы , задейств ованных для поддержки объекта критический раз дел. Механизм критических разделов основан на принципе взаимного исключения (mutual exclusion). Этот термин нам еще встретится при дальнейшем рассмотрении синхронизации потоков . Только один поток может быть владельцем критического раздела в каждый конкретный момент времени . Следовател ьно , один поток может войти в критический раздел , установить значения полей ст р уктуры и выйти из критического раздел а . Другой поток , использующий эту структуру , также мог бы войти в критический разде л перед осуществлением доступа к полям ст руктуры , а затем выйти из критического раз дела. Обратите внимание , что возможно определен ие нес кольких объектов типа критический раздел , например, cs1 и cs2. Если в программе имеется четыре потока , и два первых из них разделяют некоторые дан ные , то они могут использовать первый объе кт критический раздел , а два других потока , также разделяющих другие данные , могут использовать второй объект критический разде л. Обратите внимание , что надо быть весьм а осторожным при использовании критического р аздела в главном потоке . Если вторичный по ток проводит слишком много времени в его собственном критическом разд еле , то э то может привести к "зависанию " главного п отока на слишком большой период времени. Объект Mutex Существует одно ограничение в использовании критических раздел ов . Оно зак лючается в том , что их можно применять для синхронизации потоков только в рамках одного процесса . Но быв ают случаи , когда необходимо синхронизировать действия потоков различных процессов , которые разделяют какие-либо ресурсы (например , память ). Использова т ь критические разделы в такой ситуации нельзя . Вместо них подключ аются объекты типа mutex (mutex object). Составное слово "mutex" происходит из словосочетания "mutual exclusion", что означает взаимное исключение , и очень точно отражает назначение объектов. Мы хотим предотвра тить возможность прерывания потока в программ е до тех пор , пока не будет выполнено обновление или использование разделяемых дан ных . Уведомления о событиях Мы можем определить понятие большой работы как действи я , выполняя которые , программа нарушит "правило 1/10 секунды ". Пр имерами большой работы могут служить : проверк а орфографии в текстовых процессорах , сортиро вка и индексирование файлов баз данных , пе ресчет э лектронной таблицы , печать и д аже сложное рисование . Конечно , как мы уже знаем , лучшее решение состоит в следовани и "правилу 1/10 с екунды ", т . е . в передаче большой работы вторичным потокам обработки . Эти вторичные потоки не создают окон и , значит , не ог ра ничены "правилом 1/10 секунды ". Часто бывает , что вторичному потоку на до проинформировать первичный поток о том , что он завершился , или первичному потоку надо прервать работу , выполняемую вторичным потоком. Локальная память потока Глобальные переменн ые в многопоточных программах (так же как и любая выделенная память ) разделяются ме жду всеми потоками в программе . Локальные статические переменные функций также разделяются между всем и потоками , использующими э ту функцию . Локальные автоматические переменные в функции являются уникальными для каждого потока , потому что они хранятся в сте ке , а каждый поток имеет свой собственный стек. Может возникнуть необходимость иметь пост оянную облас ть памяти , уникальную для каждого потока . Например , функция strtok язы ка С , которая уже упоминалась в этой г лаве , требует такого типа память . Нет сомн ений , что С его не поддерживает . В Windows 95 имеется четыре функции , поддерживающие эту память , которая н азывается локальной памятью потока (thread local storage, TLS). Первичный поток вызывает функцию JTsAlloc для получения значения ин декса : dwTlsIndex = TIsAlloc () ; Он может хранит ься в глобальной переменной или может быт ь передан функции потока в параметр е-с труктуре. Функция потока начинается с выделения памяти для структуры данных и с вызова функции TIsSetValue, используя индекс , получе нный ранее : TIsSetValue (dwTlsIndex, GlobalAlloc (GPTR, sizeof (DATA))) ; Это действие ус танавливает соответствие указате ля с конк ретным потоком и конкретным индексом в по токе . Теперь , любая функция , которой нужно использовать этот указатель (включая саму баз овую функцию потока ), может использовать код , подобный такому : PDATA pdata ; pdata = (PDATA) TIsGetValue (dwTlsIndex) ; Теперь она може т изменять значения pdata->a и pdata->b. Перед завершением функции потока необх одимо освободить захваченную память : GlobalFree (TIsGetValue (dwTlsIndex)) ; Когда все поток и , использующие эти данные будут завершены , первичный поток освобожд ает индекс : TIsFree (dwTlsIndex) ; Полезно посмотреть как организована локальная память потока . (Мне неизвестно , как в действительности Windows 95 это делает , но описываемая схема вп олне правдоподобна .) Во-первых , функция TIsAlloc могла бы просто выделить блок памяти (длиной 0 байт ) и вернуть значение индекса , ко торый является указателем на этот блок . Ка ждый раз при вызове функции TIsSet Value с этим индексом блок памяти увеличивается на 8 байт с помощью функции GlobalReAlloc. В этих 8 байтах хранятся идент ификатор пото ка , вызывающего функцию , полученный с помощью функции GetCurrentThreadID, и указатель , переданны й функции TIsSetValue. Функция TIsGetValue пр осто использует идентификатор потока для поис ка в таблице , а затем возвращает указатель . Функция TZs Fr ee освобождает блок памяти. Ре ализация многопоточности в Delphi Стандартный мастер модулей в Delphi автоматически создает модуль содержащий класс потока с указанным именем . Весь код который необходимо вынес ти в отдельный поток помещается в метод класса Ex ecute . Базовый класс для создания по тока пользователя – TThread TThread = class protected procedure DoTerminate; virtual; procedure Execute; virtual; procedure Synchronize(Method: TThreadMethod); property ReturnValue: Integer; property Terminated: Boolean; public constructor Create(CreateSuspended: Boolean); procedure Resume; procedure Suspend; procedure Terminate; function WaitFor: LongWord; property FreeOnTerminate: Boolean; property Handle: Thandle; property Priority: TthreadPriority; property Suspended: Boolean; property ThreadID: Thandle; property OnTerminate : TnotifyEvent ; end ; Процесс , породивший поток может гибко управлять его состояни ем : приоритетом Priority ; приостановить и прод олж ить его исполнения , а так же до срочно завершить выполнение потока. Для вызова методов VCL необходимо синхр онизировать дочерний поток с главным . Для этого служит процедура Synchronize(Method:TThreadMethod); unit Unit1; interface uses Classes; type TSam ples = class(TThread) private Private declarations protected procedure Execute; override; end; implementation Подсказка Delphi по поводу Synchronize. Important: Methods and properties of objects in VCL can only be used in a method called using Synchronize, for example, Synchronize(UpdateCaption); and UpdateCaption could look like, procedure Samples.UpdateCaption; begin Form1.Caption := 'Updated in a thread'; end; Samples procedure TSamples.Execute; begin Здесь должен быть размещен код по тока end; end. Список используемой литературы 1. Turbo Pascal for Windows в 2-х томах . Нейл Рубен кинг Пер . с англ . – М .:Мир , 1993, 536 с ., ил. 2. Теория и практика C++. Герберт Ши лдт . пер . с англ . – СПб .: BHV – Санкт-Петербург , 1996. 416 с ., ил. 3. Программирование для Windows 95; в 2-х томах . Чарльз Петзолд . пер . с англ . – СПб .: BHV – Санкт-Петербург , 1997. – 752 с ., ил. 4. Микропроцессоры 80x86 Архитектура , функционирование . В.М .Михальчук А.А.Ровдо С.В.Рыжиков Мн .: Битрикс , 1994. - 400с. В моей работе были рассмотрены основные пр инципы многозадачности и многопоточности . Приведе ны примеры оформления многопоточных приложений на Delphi. В дальнейшем многозадачная технология пол учит дополнительное развитие . В посл еднем вышедшем релизе Windows под названием Windows2000 для поддержки многозадачности используются так называемые объекты-задания сим метрично распределяющиеся между процессорами . Для ускорения работы мощных серверных сис тем используют машины на базе 2,4 и даже 8 процессорах . Такое серверное программное обеспечение как Windows NT4.0, Unix, Linux так же поддерживает SMP – симметричную мультипроцес сорную обработку данных . Работа таких систем была бы невозможна без использова ния алгоритмов многозадачности и многопоточности.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Сержант обучает новобранцев:
- Считаю до трёх, и вы бежите. Раз... два... Эй, вы там, Рабинович! Я же ещё не сказал "три"!
- Ах, товарищ сержант, они тут все ослы! А я-то знаю, что вы вот-вот скажете "три"!
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Теория многозадачности и многопоточности", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru