Понятно. Выглядит как нормальное распределение, что интуитивно странно.

kravets, нет, не нормальное, а биномиальное распределение с
параметрами n = 10 и p = failure_rate / (repair_rate + failure_rate).
Но это так только при независимых отказах и восстановлениях.

Да, похоже

Paul Kellerman, спасибо! на машинках понятно))

kravets, и еще, согласно центральной предельной теореме (теория вероятностей)
биномиальное распределение с ростом параметра n стремится к нормальному
с матожиданием n * p и дисперсией n * p * (1 - p). Так что все вполне объяснимо.

Ага. Значит ощущение все-таки было правильным.

Добавлено через 51 секунду
Но меня больше интересует технологическая часть - как оно у Вас тикает в потоках?

Всего 12 потоков.

10 потоков имитируют 10 элементов. Каждый поток в каждый момент времени
находится в одном из двух состояний (элемент исправен, элемент неисправен),
и меняет свое состояние на противоположное через экспоненциально распреде-
ленное случайное время с матожиданием 1/failure_rate, если элемент исправен,
1/repair_rate, если неисправен. В течение этого случайного времени поток спит.
Если режим отказов Single, то все исправные потоки перед началом наработки
на отказ пытаются захватить мьютекс (специальный исключающий семафор,
его может захватить только один поток, остальные ждут пока не освободиться).
Если режим восстановлений Single, то все неисправные потоки перед началом
наработки на восстановление пытаются захватить другой аналогичный мьютекс.

Отдельный специальный поток работает и собирает статистику и рассчитывает
экспериментальные вероятности путем запроса состояний потоков - элементов
с периодичностью 0,001 сек. Можно чаще, но нет особой нужды, и так успевает,
элементы в среднем меняют состояние раз в 1 секунду при max интенсивности.

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

Вот это не понял. Они ведь все должны работать "одновременно". Зачем их блокировать?

Добавлено через 48 секунд
По сути исполнитель событийных запусков.

Добавлено через 1 минуту
Это усложняет. Проще держать в общей памяти вектор состояний, не отвлекая потоки на ответ.

1) Cемафоры используются только в режимах Single, в Independent они игнорируются.

2) Таймер используется только для обновления экрана, в моделировании не участвует.

3) Потоки не отвлекаются на ответ, они вообще не замечают таких запросов, т.к. поток
статистики тратит свое процессорное время при считывании флагов состояний потоков.
И кстати, поля (переменные) объектов-потоков так и так лежат в общей памяти процесса.

Новогодняя игрушка для технарей. Enjoy!

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

P.S. Сама по себе программа расчета (с использованием обычной вещественной float-80 обработки) была
написана давно, но особые случаи, приводящие к плохообусловленным СЛАУ (их не так много, и все же),
дающие в результате решения неверные или даже отрицательные вероятности дико раздражали, и приш-
лось погрузиться в вычислительную математику и арифметику сверхбольших целых, и победить проблему.