Современная системная архитектура?

Question

Что могло бы произойти, если бы мы использовали решение Петерсона для решения критической проблемы на современном компьютере? Насколько я понимаю, системы с несколькими ЦП могут столкнуться с трудностями из-за упорядочения операций чтения и записи в память относительно других операций чтения и записи в памяти, но является ли это проблемой большинства современных систем? Есть ли какие-либо преимущества в использовании семафоров против мьютексных блокировок?

Answer 1

Эй, интересный вопрос! Поэтому, чтобы понять, о чем вы спрашиваете, вы должны убедиться, что знаете, о чем вы спрашиваете. Критическая секция - это просто часть программы, которая не должна одновременно выполняться более чем одним из процессов или потоков этой программы одновременно. Множественный одновременный доступ запрещен, поэтому все это означает, что одновременно с системой взаимодействует только один процесс. Обычно этот « критический раздел » обращается к ресурсу, такому как структура данных или сетевое соединение.

Взаимное исключение или мьютекс просто описывает требованиечто только один параллельный процесс одновременно находится в критической секции, поэтому одновременный доступ к совместно используемым данным должен обеспечивать это «взаимное исключение».

Так что это создает проблему! Как мы можем гарантировать, что процессы работают полностью независимо от других процессов, иными словами, как мы можем обеспечить « атомарный доступ » к различным критическим разделам по потокам?

Есть несколькорешения «проблемы критического сечения», но упомянутое вами - это решение Петерсона , поэтому мы обсудим это.

Алгоритм Петерсона разработан для взаимного исключения и позволяет двум задачам совместно использовать однуиспользовать ресурс. Они используют общую память для общения.

В алгоритме две задачи будут конкурировать за критическую секцию;вам придется взглянуть на мьютекс, связанное ожидание и другие свойства немного больше для полного понимания, но справедливо только то, что в методе Петерсона процесс ждет только 1 и 1 ход, чтобы получить вход в критическую секцию,если он отдает приоритет другой задаче или процессу, то этот процесс будет выполняться до конца и тем самым позволит другому процессу войти в критическую секцию.

Это первоначальное предлагаемое решение.

Однакоэто не дает гарантии работы на современных многопроцессорных современных архитектурах и работает только для двух одновременных задач. Когда речь заходит о чтении и записи, на современных компьютерах это выглядит довольно беспорядочно, так как в нем выполняется неупорядоченный тип выполнения, поэтому иногда последовательные операции выполняются в неправильном порядке и, следовательно, существуют ограничения. Я предлагаю вам также взглянуть на замки . Надеюсь, это поможет:)

Может кто-нибудь еще придумать что-нибудь, что я мог бы пропустить?

Answer 2

Насколько я понимаю, системы с несколькими ЦП могут столкнуться с трудностями из-за упорядочения операций чтения и записи в памяти относительно других операций чтения и записи в памяти, но является ли это проблемой для большинства современных систем?

Нет. Любые современные системы с «менее строгим» упорядочением памяти будут иметь способы сделать упорядочение памяти более строгим там, где это имеет значение (например, ограждения).

Есть ли какие-либо преимущества в использовании семафорных мьютекс-блокировок VS?

Мьютексы, как правило, проще и быстрее (так же, как логическое значение проще, чем счетчик);но игнорируя накладные расходы, мьютекс эквивалентен семафору с «счетчиком ресурсов = 1».

Что может произойти, если мы воспользуемся решением Петерсона для решения проблемы критической секции на современном компьютере?

Большая проблема здесь заключается в том, что большинство современных операционных систем поддерживают некоторые виды многозадачности (например, несколько процессов, где каждый процесс может иметь несколько потоков), обычно есть 100 других процессов (только для одной ОС), и современныеаппаратное обеспечение имеет управление питанием (где вы пытаетесь избежать энергопотребления, переводя процессоры в спящий режим, когда они не могут выполнять полезную работу). Это означает, что (неограниченное) ожидание вращения / занятости является ужасной идеей (например, вы можете потратить впустую N процессоров, пытаясь получить блокировку, в то время как задача, которая в данный момент удерживает блокировку, не выполняется ни на одном процессоре, потому что планировщик решил, что1234 другие задачи должны получить 10 мс процессорного времени каждая).

Вместо этого;чтобы избежать (чрезмерного) вращения, вы хотите попросить планировщик заблокировать вашу задачу до тех пор, пока блокировка не будет фактически получена;и (особенно для сильно спорных блокировок) вы, вероятно, захотите «справедливости» (чтобы избежать риска проблем со временем, которые приводят к тому, что некоторые задачи часто оказываются удачными, в то время как другие задачи голодают и не достигают прогресса).

«нет вращения» или «короткое вращение» (чтобы избежать накладных расходов планировщика в тех случаях, когда задача, удерживающая блокировку, действительно может / действительно снимает ее быстро);затем задача ставится в очередь FIFO, а планировщик отдает ЦП другой задаче или переводит процессор в спящий режим;где, если блокировка снята, планировщик запускает первую задачу в очереди FIFO. Конечно, это никогда не бывает так просто (например, для повышения производительности вы хотите сделать как можно больше в пользовательском пространстве; вам необходимо особое внимание и взаимодействие между пользовательским пространством и ядром, чтобы избежать условий гонки - блокировка снимается до того, как задачапоставить в очередь ожидания).

К счастью, современные системы также предоставляют более простые способы реализации блокировок (например, «атомарное сравнение и своп»), поэтому нет необходимости прибегать к алгоритму Петерсона (даже если он только для вставки /удаление задач из очереди FIFO реальной блокировки).