Обсуждение:Семафор (программирование)

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Сопровождение статьи[править код]

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

Рационализация[править код]

Терминология[править код]

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

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

Преамбула[править код]

Понятия легковесного семафора, двоичного и вычислительного — тривиальные, поэтому описаны в преамбуле. Мьютексный семафор является синонимом мьютекса, поэтому тоже описан в преамбуле, но кратко (есть соответствующая статья) и в контексте отличий от обычных семафоров. Отдельный раздел для классификации семафоров не требуется, т. к. краткой информации вполне достаточно, и она хорошо вписывается в преамбулу. Слабые и сильные семафоры в преамбуле не упомянуты преднамеренно, поскольку не являются столь же значимыми по сравнению с остальными понятиями. Как минимум в документации на реализацию семафоров не пишут, какие семафоры конкретная реализация предоставляет.

Раскрытие темы[править код]

Для полного раскрытия темы в статье должны быть описаны основные алгоритмы, в которых обычно используется семафор, а также популярные классические задачи. Не имеет смысла рассматривать задачи, не имеющие решения с помощью семафоров, например, задачу про курильщика от Сухаса Патила. Однако можно упомянуть, что подобные задачи не имеют решения. Решения упрощённых классических задач имеет смысл описывать или упоминать, если они получили достаточную популярность или дают новый шаблон использования семафора, который в том или ином виде отсутствует в других задачах и типовых вариантах использования.

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

Тем не менее, в статье можно описывать стандартизованное или общепринятое API на уровне операционных систем и общие практики его использования, в силу значимости тематики.

Особенности работы семафоров на уровне процессора могут быть общими для достаточно большого количества примитивов синхронизации, поэтому должен быть минимум информации, описываемый именно в контексте семафоров. Подобная информация помогает понять, как устроены семафоры на самом низком уровне, что необходимо для понимания того, почему их вообще придумали. Из архитектур должны быть описаны лишь популярные, к которым на 2019 год относятся x86/x86_64 и ARM. Можно было бы описать и менее популярный, но значимый MIPS, но в таком случае описание должно быть полным, качественным и согласно источникам. Однако, если возникнет необходимость описать другие архитектуры, проще это сделать отдельным обобщающим разделом «В других архитектурах», особенно, если количество описываемых архитектур перевалит за 3.

Ответственные редакторы[править код]

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

Ответственными редакторами статьи являются: У:D6194c-1cc (с 2019).