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

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

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

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

Приветствую!

Скорее всего он "разводил" Вас с результатами работы программы пытаясь понять насколько Вы разбираетесь в принципах функционирования RTOS.
Суда по результатам анализа - "развод" ему удался
Поскольку трудно себе представить RTOS планировщик которой работает после каждой инструкции CPU.

Успехов! Rob.

Переменная count не является volatile, поэтому предположение о том, во что компилируется count++ неверно.
Далее в связи с этим совершенно непонятно, во что вся эта милая конструкция превратилась после оптимизатора.

Проверял ли задающий вопрос правильность работы железа? Таблицы размещения? Может у него сегмент data размещен в непотребном месте. И далее в таком вот духе..

В общем "почему неправльно написанная программа работает неправильно?" В интервью это называется open-ended question. Ответ на такой вопрос не обязательно должен быть правильным. Он должен показать ход ваших мыслей и/или дать потенциальному работодателю формальный повод для отказа ("он ответил так, а надо было сяк").

Не переживайте. Кстати, какой результат в итоге? Сделали вам предложение?

Может у него был 8 битный микроконтроллер, а у него count типа int. Пока один меняет один полубайт, то другой поток меняет другой полубайт.

Принимайте меня на работу, а то я немогу найти работу в своем городе.

Неправильно реализована функция printf на железке, а точнее stdout.
В терминал отправляется правильное число 25 и приложение тут же завершается.
В сдвиговый регистр (если терминал на COM-порте) только и успели положить один символ "2", и пока этот символ выдвигался в линию - приложение закрылось, закрыв за собой все открытые устройства, и терминал в том числе, очистив при этом передающий буфер.

Сообщение отредактировал gerber - Jul 31 2014, 13:44

похоже. только а) принтф может стоять и тупить пока всё не отправится. б) не согласовывается с уточнением, что результат не зависит от числа потоков и величины фора. а там не 25 может получится, а и 80, к примеру.

25. Почему? Патамушта! (кооперативная, вытесняющая, гибридная) Патамушта! (возьмете, расскажу )

Прошу прощения, по условиям задачи RTOS вытесняющая, процессор 32бит, count++ компилируется именно в те 3 ассемблерные команды, которые приведены и дело точно не в printf. Даже ежу понятно, что этот код никуда не годится, так не делают и т.п. Но вопрос был именно почему работа определённой программы приводит к определённому результату, шаг за шагом..

Жду..

Для начала неплохо бы понять, в какой ОС есть функция thread_join() и как она работает.

Это условная RTOS. thread_join() просто ждёт пока все потоки завершатся

Нагло врет ваш интервьюер, если поток будет 1 все будет нормально ))))

99.9 % дело не вытеснении, на 32 разрядном проце каждая такая задача, уверен, успеет завершится, прежде чем будет вытеснена. Что и подтвердил мой комп - 25 ответ . Хотя код еще некорректен еще и потому, что счетчик не объявлен как volatile (а это, на самом деле, обязательно, только сегодня обсуждали на работе). Но причина вывода "2", вряд ли в этом. Хотя несколько забавно просить найти ошибку в псевдокода с псевдооперационкой. А может оператор ++ где-то переопределен как "присвоить 2" ?


Совершенно верно

Условная ОС не может быть проверена в железе, как сказано в первом сообщении.

Тут дело не в особенностях какого-то конкретного железа или RTOS (как кстати частота тиков планировщика связана с разрядностью процессора?). Есть определённая последовательность действий, которая в итоге приводит к результату 2. Какие это могут быть действия описаны в листинге в условии задачи. Тут вопрос исключительно на логику.

Не уклоняйтесь от решения задачи, вдруг тоже такое когда-нибудь попадётся

А разве можно решить нерешаемое?