> Внимательно просмотрел исходник. Мысли следующие:
>
> 1) почему наследование от TService сделано публичным? Какие функции
> TService предполагается использовать снаружи?
По аналогии с штатным TMutex. Он тоже с публичным наследованием. Т.к. я никогда не размышлял глубоко над потрохами scmRTOS, то максимально повторял уже существующий код.
> 2) Не нравится мне возможность вызова со значением по-умолчанию и вот
> почему:
> вызывая mutex.lock() без параметров программист предполагает, что
> выход из этой функции будет со 100% гарантией захвата. И старая
> реализация без параметра это обеспечивала. В новой же, если во время
> ожидания захвата будет вызвана
> force_wake_up() - lock() вернется с незахваченным ресурсом. А весь
> предыдущий код написан с учетом того, что она void и проверки захвата не
> содержит. И хотя я пока еще не использовал wakeup() и force_wake_up(),
> все же сделал бы отдельную функцию для захвата с таймаутом и
> отдельную для безусловного захвата, т.е. без параметра. И если развивать
> эту логику, то lock() с параметром, равным 0 переадресовывал бы в
> lock_softly().
Вот такие вот нюансы - это основная причина, почему я стараюсь переложить ответственность за новый функционал в оси на людей, понимающих устройство ОС гораздо глубже меня.
Я - пользователь этой замечательной оси. И, по некоторым причинам, не хочу быть разработчиком. Как пользователь, я предлагаю нужный мне новый функционал, но аккуратная его реализация - дело людей с хорошим пониманием устройства оси.
Буду рад, если кто-то, например, Сергей Борщ, возьмется за реализацию TTimedMutex.