Большинство современных способов исключить присутствие пациента на операции позволяют сделать это надежно и без побочных эффектов. В моей практике, давно, еще в СССР, был единственный случай пробуждения пациентки на операции: прекратилась подача кислорода и пришлось с кислородно-закисной смеси перейти на воздух. Пациентка проснулась, испугалась, я объяснил ей ситуацию и, поскольку анальгезия была адекватной, операция продолжилась без проблем. Жалоб не было.
Удешевление и упрощение мониторного оборудования расширяет его применение, но это скорее дополнение, чем необходимость.
Его или подобные методы анализа в 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. И получал бы «срезы» на любой вкус. Ну а если надо экономить память — без индивидуально заточенного решения все равно не обойтись…
Чтобы задуматься о причинах надо сначала хотя бы отсрочить умирание…
В смысле махнуть две по сто-писят в пятницу норм?
Удешевление и упрощение мониторного оборудования расширяет его применение, но это скорее дополнение, чем необходимость.
Вот поэтому я лет 20 как программист, а Вы можете обезболиваться самостоятельно;-).
В случаях, когда с головой во время операции или процедуры может что-то произойти — мониторят. Ну, или когда результат процедуры нельзя под наркозом оценить без ЭЭГ, как при электросудорожной терапии.
А существование обратного баттхерта допускаете?
Ой ли? Кажется, что в разных планировщиках используются разные алгоритмы. Вроде даже есть теорема, что гарантия прогресса многопоточного приложения существует только если все потоки имеют равный приоритет и получающий квант поток выбирается случайным образом из пула готовых.
Не уверен, что в size_t contains_symbol(char *symbols, char symbol) имеет смысл говорить о возврате -1 — она превратиться в максимальное беззнаковое целое. Компилятор, увидев проверку возвращенного значения на отрицательность, будет обескуражен. Может, лучше для положения в массиве использовать ptrdiff_t?
Ну и объявлять аргумент char в C не слишком осмысленно, хотя и можно.
А на каких снимках видны отдельные клетки?