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

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

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

Рационализация

Терминология

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

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

Преамбула

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

Раскрытие темы

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

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

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

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

Ответственные редакторы

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

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

Математические применения семафоров отличаются от практических применений

Семафоры одна из самых старых абстракции в области параллельных вычислений, поэтому многие решения задач или доказательства теорем были сформулированы с использованием семафоров. Но статья этого не учитывает.

К примеру, "Служит для построения более сложных механизмов синхронизации" с точки зрения математики, особенно прошлого века - достаточно продуктивное положение.

Но с точки зрения практики, особенно на современных процессорах, такой подход контрпродуктивен. Скажем, в терминологии С++, захват и освобождение мьютекса имеют семантику видимости изменений тоже захвата и освобождения (см. "synchronize with (6.9.2)" C++20), а у семафора обе операции P() и V() имеют семантику чтение-модификация-запись, таким образом реализация мьютекса на основе семафора будет принципиально менее эффективной.

Или вопрос, аварийного завершения потока, у семафоров нет аналога кода кода ошибки EOWNERDEAD функций pthread_mutex_lock()/pthread_mutex_trylock(). Т.е. семафоры на мьютексах реализовать можно, а PTHREAD_MUTEX_ROBUST мьютексы на семафорах нельзя.

В общем, стоит как-то в статье отделить математику от практики. Сергей Леонтьев, Крипто-Про (обс.) 12:28, 2 сентября 2021 (UTC)

• По поводу реализации механизмов синхронизации, – я на своей памяти достаточно много всякого интересного реализовал. Последнее время даже подсел на линуксовые семафоры, которые можно ставить на ожидание вместе с другими файловыми дескрипторами, это очень удобно. Мьютекс же – это самое простое, что можно сделать, да, не самое эффективное именно на семафорах.
  По поводу математики, если будут источники, описывающие семафоры в контексте доказательств чего-либо, можно реанимировать статью Семафор (информатика). D6194c-1cc (обс.) 20:26, 30 марта 2023 (UTC)

Функции Windows API

@88.155.107.194: Писать Abc(), если такой функции нет, нельзя. Скобки явно указывают, что это название функции, одна функции без суффикса A или W нет. Поэтому это ошибка.
Касательно Языка Си, Windows API к нему не относится, а windows.h библиотекой не является.
Если нет источника на функцию OpenSemaphoreA(), то убирать суффикс у единственной функции тоже не нужно. Требуется источник. D6194c-1cc (обс.) 16:20, 30 марта 2023 (UTC)

• Пускай будет по вашему, но давайте без "Функции CreateSemaphore" а будет "CreateSemaphoreA() или CreateSemaphoreW()". Насчет языка Си, это факт, просто почему у вас pthreads написано, хотя он тоже не стандартный, а потом вы его заменили на threads.h в котором нет семафоров, и тип еще тот не указали. В данном случае удаляю информацию про Си вообще. 46.96.154.113 17:17, 30 марта 2023 (UTC)
  • Там ещё есть функции серии Ex. Как минимум их 4.
    Про threads.h - это меня глюкануло, бывает, отменил. D6194c-1cc (обс.) 17:27, 30 марта 2023 (UTC)
    • Еще сноски бот сломал 46.96.154.113 17:30, 30 марта 2023 (UTC)
      • Жуть какая, убрал. Сноски позже заменю на шаблон, чтобы по ГОСТ было. D6194c-1cc (обс.) 17:33, 30 марта 2023 (UTC)
  • Понятно 46.96.154.113 17:27, 30 марта 2023 (UTC)
    • Убрал Си, тут Вы правы. D6194c-1cc (обс.) 17:33, 30 марта 2023 (UTC)
  • Если есть ещё замечания, буду рад услышать. D6194c-1cc (обс.) 17:39, 30 марта 2023 (UTC)
    • Да в принципе все 46.96.154.113 17:46, 30 марта 2023 (UTC)