#c #linux #concurrency #pthreads
#c #linux #параллелизм #pthreads
Вопрос:
Для академической программы, которую я пишу, было бы очень полезно, чтобы набор потоков одновременно входил в процесс перепланирования. Итак, мой вопрос в том, есть ли гарантия для pthread_cond_broadcast (3) завершения маркировки всех потоков как готовых до того, как первый поток будет перенесен?
Или, выражаясь иначе, может ли вызывающий поток покинуть состояние выполнения, пока больше 0, но не все затронутые потоки конкурируют за выполнение?
Редактировать: Поскольку произошла некоторая путаница. Я просто спрашиваю, гарантирован ли ожидаемый результат каким-либо стандартом, который я, похоже, не могу найти.
Комментарии:
1. Это действительно звучит как проблема XY . Что вы пытаетесь решить? Как вы вообще определяете такие вещи, как «в то же время» и «пока» для процессов и событий, которые происходят за наносекунды?
2. Как вы ожидаете, что на самом деле будут соблюдены такие мелкие детали конкретной платформы? Как вы определяете, «готов» ли конкретный поток, и что это значит для вашей академической программы?
3. Это не проблема XY. Я определяю «в то же время», как в: не существует момента, когда процессор выбирает следующий поток для планирования, где конкурирует только часть затронутых потоков. Также в данных системах выход может занять несколько микросекунд, что неприемлемо во время выполнения этого вызова.
4. процессор ?? Теперь определите это . А также определяет «конкурирующий». Вам нужно взглянуть на такие вещи, как конвейеры выполнения . В выполнении программы нет особого «момента». Также в данных системах выход может занять несколько микросекунд, что неприемлемо во время выполнения этого вызова. Так что это проблема XY. Почему это «неприемлемо»? Какую актуальную проблему вы пытаетесь решить / избежать?
5. Единственное, что объединяет конвейеры выполнения и планирование потоков, — это то, что планирование использует инструкции, которые могут быть конвейеризованы. Планирование потоков на случай, если вам интересно. Это не проблема XY, поскольку цель буквально состоит в том, чтобы потоки конкурировали за состояние выполнения (рисунок 4.4) . Также я никогда не заявлял, что это проблема , которую я пытаюсь решить / избежать. Я спрашивал, знает ли кто-нибудь о стандарте, который гарантирует ожидаемое поведение.