Всем привет!
Недавно был на интервью в одной компании и "застрял" на вопросе про RTOS. После недели поисков ответ так и не был найден..
Условие задачи такое: есть 5 потоков, каждый из них увеличивает в цикле общую переменную count на 1. После завершения работы этих потоков, значение count выводится на экран.

Внимание вопрос: почему программа печатает 2??
Договорились с интервьювером, что операция count++ состоит из 3х ассемблерных команд:

Т.к. переменная count не защищена ни мьютексом, ни критической секцией, самый пессимистичный вариант, который я "раскрутил" выглядит так:

т.е. в результате один поток делает override результата второго потока и count = 1 после выполнения всех потоков (а не 5, как было бы с мьютексом).
Но: хоть один из потоков все равно увеличит count на 1 в этой схеме, т.е. в результате работы программы count будет не меньше, чем 5.
Как же получается 2? (со слов интервьювера, он наблюдал такой эффект в реальном железе). Подсказка от интервьювера: результат не зависит ни от количества потоков, ни от количества итераций в цикле for

А если потоков 0?
А если потоков 1, а итераций 0?

Резальтат, равный 2, печатается постоянно или нужно объяснить ситуацию с крайне низкой вероятностью, когда печатается 2 ?

что возвращает вызываемая функция
void thread(void)

разве не "ничего"?

А какой это язык программирования ?

типа с

На работу всё-таки взяли, попробую найти там этого интервьювера и докопаться до истины..

Всё гораздо проще - просто посмотрите дебаггером - всё зависит от оптимизации - и ваш интервьюер просто не сказал вам все данные. но если добавить volatile - проблем бы было меньше. Это называется - срубить не разбираясь. Если вы сразу не задали вопрос про оптимизацию и volatile - значит понимания нет - а код тут не при чем

Спасибо за участие в обсуждении)) Но, мне кажется, что дело не в этом совершенно. Задача имеет чисто алгоритмическое, логическое решение. Результат и решение не имеют привязки к аппаратной платформе, компилятору, оптимизатору и т.п. Этот код предоставлен as-is и вопрос не в том, как сделать из него нормальный код (кстати, если бы переменная была volatile, это разве что-нибудь бы поменяло?).

Типа ОСь очень реального времени Видимо 2, потому что первый поток из пула успевает инкрементировать счетчик, поскольку пока еще нет потоков, способных ему помешать, последний поток из пула инкрементирует счетчик, поскольку потоки, способные ему помешать уже завершились.

Планировщик переключает задачи после каждой инструкции!?

В реальности, естественно, переключать контекст после каждой инструкции накладно.
Но, видимо, в данном конкретном случае интервьюер предполагал, что контекст переключается после каждой инструкции) Не знаю уж какой эффект он там наблюдал в реальном железе, лажу после оптимизации или что. Но думаю, что свои 2 он интерпретировал как-то так.

Похоже алгоритмического решения не будет.
Интернет не знает таких функций как thread_create(thread, 5) и thread_join() с такими типами аргументов, а потому потом можно будет грузить на их счет все что угодно.
Это подстава.

Можно предположить, что имелись в виду POSIX функции pthread_create и pthread_join, но они не умеют работать без аргументов и с массивами потоков.

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

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

Что это за загадочная "синхронная фаза"?

Если код основан на POSIX, то можно кое что восстановить.

pthread_create создает и устанавливает готовность задач.
Поскольку приоритет не указывается, то логично предположить, что он будет равен приоритету задачи main.

Рассматриваем что могло быть на реальном железе:

До вытеснения тут явно не дойдет. Тик осей редко бывает короче 10 мс.
Значит вся работа задач начнется после вызова thread_join
Без аргументов thread_join не бывает, возможно это переопределение оригинальной функции и в этой реализации ожидание всех задач производится по очереди с помощью семафоров.
Но возможно реализован механизм ожидания маски флагов от всех задач сразу.
В любом случае задачи выполнятся последовательно не вытесняя друг друга, поскольку имеют одинаковый приоритет.
Случится прерыванию во время выполнения тех задач крайне мала, поскольку все задачи выполнятся менее чем за микросекунду.

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

И тогда произойдет неожиданный выход из thread_join.
Далее заход в функцию printf и там возможно где-то ось не на долго переключится на одну из оставшихся активных задач во время ожидания прерывания по готовности чего-то периферийного.
Вот тут и успеет какая-то из задач инкрементировать count до прерывания и переключения контекста на драйвер printf.

Во всяком случае у меня аналогичный код под MQX работает идеально при любом уровне оптимизации и всегда выдает 25