Большинство современных способов исключить присутствие пациента на операции позволяют сделать это надежно и без побочных эффектов. В моей практике, давно, еще в СССР, был единственный случай пробуждения пациентки на операции: прекратилась подача кислорода и пришлось с кислородно-закисной смеси перейти на воздух. Пациентка проснулась, испугалась, я объяснил ей ситуацию и, поскольку анальгезия была адекватной, операция продолжилась без проблем. Жалоб не было.
Удешевление и упрощение мониторного оборудования расширяет его применение, но это скорее дополнение, чем необходимость.
Его или подобные методы анализа в frequency domain и используют где-то с середины 80-х годов прошлого века. Мешает отсутствие оборудования, поскольку в нормальных условиях закупаются более приоритетные вещи. И накладывать лишние электроды, да еще не самые простые (раньше так, как сейчас не в курсе) хлопотно для столь незначительной пользы.
Я бы вас засудил за халатность в этом случае.
Вот поэтому я лет 20 как программист, а Вы можете обезболиваться самостоятельно;-).
Как анестезиолог с приличным стажем могу сказать, что в большинстве случаев мониторить ЭЭГ во время анестезии
Не особенно полезно, практически ту же информацию можно легко получить без
Из-за предыдущего пункта неудобства и затраты на такой мониторинг не оправдываются
В случаях, когда с головой во время операции или процедуры может что-то произойти — мониторят. Ну, или когда результат процедуры нельзя под наркозом оценить без ЭЭГ, как при электросудорожной терапии.
Потоки с одинаковыми приоритетами запускаются в порядке очереди.
Ой ли? Кажется, что в разных планировщиках используются разные алгоритмы. Вроде даже есть теорема, что гарантия прогресса многопоточного приложения существует только если все потоки имеют равный приоритет и получающий квант поток выбирается случайным образом из пула готовых.
Придирки.
Не уверен, что в size_t contains_symbol(char *symbols, char symbol) имеет смысл говорить о возврате -1 — она превратиться в максимальное беззнаковое целое. Компилятор, увидев проверку возвращенного значения на отрицательность, будет обескуражен. Может, лучше для положения в массиве использовать ptrdiff_t?
Ну и объявлять аргумент char в C не слишком осмысленно, хотя и можно.
Соглашусь, что «синхронизация», «передача сообщения» и другие слова здесь не совсем к месту. Мне кажется, что речь здесь идет скорее о том, что в Java называют публикацией: если поток 1 успел записать, то поток 2 прочтет то, что он записал. Без WRITE_ONCE/READ_ONCE и smp_* — не факт.
ИМХО, если свойств немного, то это чересчур. А если и свойств, и объектов много, то я взял бы в качестве «корзины» embedded in-memory database. И получал бы «срезы» на любой вкус. Ну а если надо экономить память — без индивидуально заточенного решения все равно не обойтись…
Довольно много игрался с конечными автоматами и симпатизирую этому подходу. Но по моему личному опыту очень привлекательная идея FSM при реализации только в коде плохо масштабируется на большие/сложные автоматы. Нужны инструменты с визуализацией, моделированием и верификацией, но они обычно порождают не самую эффективную реализацию, нормально использовать которую можно только при избытке вычислительного ресурса (типа CCXML для ненагруженной телефонии).
Поэтому если с ресурсами не очень, как на МК, то с годами стал предпочитать более прямолинейный подход с упором на дизайн и продумывание задачи: та или иная форма «акторной архитектуры» с максимальной декомпозицей событий и провдедением четко ограниченных и нагруженных контекстом с данными событий через очередь в тот или иной «актор»-обработчик. Рад был бы, если шаблоны тут сильно помогали, но у меня не сложилось такого впечатления. Нет, если взять хороший фреймворк типа SObjectizer или QP, то получается очень даже поддерживаемо.
А увлечение шаблонизацией где надо и не надо — это детская болезнь, которая проходит с появлением реальной ответственности за сроки и поддержку своих проектов. Вырабатывается чувство, когда просто интересно и когда полезно.
Возможны разные варианты, но в целом аллергические заболевания росли в CCCР и постепенно привлекали внимание. В конце 60-х прошлого века в Калуге никому не приходило в голову, что у меня, пацаненка, сенная лихорадка. И пытались меня лечить от гайморита. А в 70-х, в Москве, уже предложили специфическую десенсибилизацию в аллергологическом отделении. Их было одно или два на всю Москву, но уже были.
Удешевление и упрощение мониторного оборудования расширяет его применение, но это скорее дополнение, чем необходимость.
Вот поэтому я лет 20 как программист, а Вы можете обезболиваться самостоятельно;-).
В случаях, когда с головой во время операции или процедуры может что-то произойти — мониторят. Ну, или когда результат процедуры нельзя под наркозом оценить без ЭЭГ, как при электросудорожной терапии.
А существование обратного баттхерта допускаете?
Ой ли? Кажется, что в разных планировщиках используются разные алгоритмы. Вроде даже есть теорема, что гарантия прогресса многопоточного приложения существует только если все потоки имеют равный приоритет и получающий квант поток выбирается случайным образом из пула готовых.
Не уверен, что в size_t contains_symbol(char *symbols, char symbol) имеет смысл говорить о возврате -1 — она превратиться в максимальное беззнаковое целое. Компилятор, увидев проверку возвращенного значения на отрицательность, будет обескуражен. Может, лучше для положения в массиве использовать ptrdiff_t?
Ну и объявлять аргумент char в C не слишком осмысленно, хотя и можно.
А на каких снимках видны отдельные клетки?
Поэтому если с ресурсами не очень, как на МК, то с годами стал предпочитать более прямолинейный подход с упором на дизайн и продумывание задачи: та или иная форма «акторной архитектуры» с максимальной декомпозицей событий и провдедением четко ограниченных и нагруженных контекстом с данными событий через очередь в тот или иной «актор»-обработчик. Рад был бы, если шаблоны тут сильно помогали, но у меня не сложилось такого впечатления. Нет, если взять хороший фреймворк типа SObjectizer или QP, то получается очень даже поддерживаемо.
А увлечение шаблонизацией где надо и не надо — это детская болезнь, которая проходит с появлением реальной ответственности за сроки и поддержку своих проектов. Вырабатывается чувство, когда просто интересно и когда полезно.
Сам себе могилу роет!
Руки мылом ты не мой!
Береги защитный слой!