Как стать автором
Обновить
38
0
Илья Свирин @isvirin

Пользователь

Отправить сообщение
Может быть вообще отдельный пост сделать по ОЭЗ Дубна, раз уж пошла такая пьянка?:)
Мы уже давно вынашивали мысль разместить зеркало наших ресурсов, где-нибудь в Европе. Но, как водится, пока гром не грянет, мужик не перекрестится;)
На языке юристов это называется форс-мажор:)
Полагаю, похожая ситуация везде ниже по течению. Есть информация по Костроме, например.
Ага, это как в анекдоте: «Друзья мои, вчера у нас было все плохо, сегодня тоже все плохо, завтра, судя по всему, тоже будет плохо. Поздравляю! Ситуация стабилизировалась!»

Это было бы смешно, когда бы не было так грустно.
Давно уже льда не было. Забыли просто…
У меня лично остается только один вопрос, почему не начали сброс воды на месяц раньше и по чуть-чуть, а не три дня назад почти на полную?
Пройти туда особой проблемы нет. Мои ребята вчера пробирались через гостиницу Резидент (после недолгих, но кровопролитных боев с тамошними администраторами пропустили на территорию). Если отсутствие электричества не смущает, то милости просим:)
Ждем пост по результатам Ваших исследований.
Все верно, просто в несколько более красивом и завуалированном исполнении.
На самом деле, большинство книжек по криптографии начинаются описания криптографического алгоритма со 100% стойкостью: есть буфер размером N и ключ размером N. Накладываем ключ на блок каким-нибудь XOR-ом и получаем «зашифрованный» блок, который принципиально не может быть подвергнут криптоанализу. Здесь ровно тот же случай:)
Почему сразу паранойей?:) Я бы сказал: зависит от ценности информации и модели угроз.
Согласен, как вариант! Но нужно понимать, что к этим 5-ти еще желательно, чтобы у получателя флешки был хотя бы еще один, участвующий в декодировании:)
Звучит, как «фи» алгоритму, но я бы назвал это просто естественным ограничением на область его применения. Те же самые ограничения на применение стеганографии. Понимание этих ограничений позволяет бороться с применением этих алгоритмов, имхо.
Если не секрет, куда предлагается их добавить?
Все верно. Этот вопрос уже поднимался чуть выше, поэтому процитирую:

> Первое правило, больше подстраховка от случая, когда вы будите выполнять вот так: L1 — L2 — U1 — L1 — … Если строго придерживаться правила, что захват всегда в одном и том же порядке, то т.к. у вас уже захвачен L2, вы не имеете права захватывать L1. Но, кто же об этом будет помнить. Поэтому и вводится правило об освобождении в порядке обратном захвату.
> Не совсем. Более цивилизованный способ это както донести этой библиотеке, что мы не справляемся. Както ее притормозить. Обычно для этого просто подвешивают листенер, а дальше часто этой библиотеке проще както дропнутые данные восстановить. Скажем перезапросить из сети или еще как.

Т.е. предлагаете, чтобы сама библиотека drop-нула то, что вы не успеваете обрабатывать?:)

> Я пришел к выводу, что дедлоки неизбежны, а избыточная борьба с ними, просто делает код сложнее в поддержке.
Простите, я адепт другой веры;) Я считаю, что дедлоки недопустимы и даже если существует лишь потенциальная угроза их возникновения при какой-то невероятной динамике, то с этой потенциальной ситуацией уже надо бороться!
Проблема всех очередей всегда состоит в том, что, если на другом конце ее не успевают опустошать также интенсивно, как набивают на другом, то в какой-то момент придется что-нибудь drop-нуть;)
Тут рецепт только один — не надо смешивать свои блокировки с блокировками внешних (тем более закрытых) библиотек. Если мы не можем их учесть в нашей модели, а следовательно, не можем гарантировать потокобезопасность использующего их кода, то надо их «гальванически развязать», например, через какую-нибудь очередь, наполняемую сторонней библиотекой, а вычитываемой нашей программой. Так мы четко локализуем место соприкосновения нашего прекрасного кода с небезопасным сторонним:)
С чем соглашусь, так это с тем, что возможны алгоритмические локи, когда программа крутится где-то в ожидании чего-то, что алгоритмически никогда не наступит. Это отдельная сложная задача — верификация алгоритмов. Но это далеко от классического понимания deadlock-a…
В ответ приведу фрагмент нашего исследования (такой у нас есть по всем распространенным платформам и языкам). Данные по средствам синхронизации JAVA получены из материалов ресурса www.sun.com (раздел «API & Docs»). Встроенные средства синхронизации синхронизируют выполнение потоков. Выполнение процессов регулируется средствами синхронизации операционной системы.
1. Замок (Lock) – исключающий семафор, обладающий возможностями:
— неблокирующего захвата;
— функцией захвата до прерывания (поток захватывает исключающий замок или ожидает его захвата до прерывания, если замок был захвачен, то во время прерывания он отпускается);
— функцией неблокирующего захвата до прерывания (ожидание здесь может идти до срабатывания таймера).
Замок представляет собой нерекурсивный исключающий семафор (может быть блокирующий или неблокирующий).
Следующие три класса замков наследуются от этого и обладают его функциональными возможностями.
2. Рекурсивный замок (Reentrant lock) – рекурсивный исключающий семафор (может быть блокирующий или неблокирующий).
3. Замок чтения/записи (ReadWrite lock) – средство синхронизации, позволяющее одновременно обращаться к ресурсу группе читающих потоков или одному пишущему. Состоит из читающих и пишущих замков. По умолчанию приоритет доступа не задан, однако, существует большое количество политик доступа. Пишущий замок может быть заменен читающим и наоборот. Данное средство синхронизации предоставляет возможность неблокирующего захвата, но на нее не распространяются правила политик доступа. Читающий или пишущий замок может быть ассоциирован с переменной кондиции.
Возможна реализация замка чтения/записи с помощью одного блокирующего исключающего семафора нерекурсивного типа и двух блокирующих сигнальных переменных без памяти.
4. Рекурсивный замок чтения/записи (ReentrantReadWrite lock) – является рекурсивным аналогом замка чтения/записи.
Возможна реализация рекурсивного замка чтения/записи с помощью одного блокирующего исключающего семафора рекурсивного типа и двух блокирующих сигнальных переменных без памяти.
5. Переменная кондиции (Condition) – сигнальная переменная, которая обладает методами:
— прерываемого ожидания сигнала;
— прерываемого ожидания сигнала до истечения заданного времени;
— прерываемого ожидания до наступления заданного момента времени;
— непрерываемого ожидания.
Сигнал сбрасывается, если нет ожидающих потоков. Возможно оповещение всех потоков, находящиеся в состоянии ожидания.
Переменная кондиции представляет собой сигнальную переменную без памяти (может быть блокирующей и неблокирующей).
6. Семафор (Semaphore) – сигнальная переменная, которая имеет счетчик, фиксирующий количество свободных пропусков на доступ к ресурсу. Поток перед получением доступа к ресурсу должен получить пропуск (можно получить несколько пропусков за один запрос). Если счетчик пропусков не положителен, запрашивающий поток переходит в состояние ожидания. Ожидание получения пропуска может быть прекращено по истечении заданного периода времени или в результате прерывания.
Операции получения и освобождения пропуска не связаны: можно освободить пропуск, предварительно ничего не получая.
Семафор представляет собой сигнальную переменную с памятью (может быть блокирующей или неблокирующей).
7. Защелка обратного отсчета (CountDownLatch) – средство синхронизации, позволяющее потокам ожидать выполнения некоторого заданного набора операций. В основе защелки обратного отсчета лежит счетчик и операция, уменьшающая счетчик на 1. Когда счетчик достигает 0, все потоки, находящиеся в состоянии ожидания, освобождаются. Счетчик нельзя переустановить. Ожидание счетчика может быть прекращено по истечении заданного периода времени или в результате прерывания.
Защелка обратного отсчета представляет собой сигнальную переменную с памятью (может быть блокирующей или неблокирующей).
8. Циклический барьер (CyclicBarrier) – средство синхронизации группы потоков. Каждый поток в этой группе выполняется до определенной точки, называемой барьером. После достижения барьера поток переходит в состояние ожидания, которое прекращается, когда все потоки достигнут барьера (каждый своего). Барьер можно разрушить. Если поток пришел в точку барьера не последним, то он ожидает одного из следующих событий:
— последний поток пришел в точку барьера;
— истекло заданное время ожидания одного из потоков;
— произошло прерывание одного из потоков;
— барьер был разрушен одним из потоков.
Циклический барьер может быть реализован на основе сигнальной переменной с памятью (может быть блокирующей или неблокирующей).
9. Обменник (Exchanger) – средство синхронизации, которое позволяет потокам обмениваться данными. Если поток достигает точки обмена, он переходит в состояние ожидания, до одного из следующих событий:
— истек заданный период времени;
— произошло прерывание;
— другой поток пришел в точку обмена, где произойдет обмен данными.
Это средство синхронизации может быть реализовано на основе сигнальной переменной с памятью (может быть блокирующей или неблокирующей).
10. Директива synchronized – критическая секция.
Представляет собой нерекурсивный исключающий семафор (может быть блокирующий или неблокирующий).

Все перечисленное прекрасно укладывается в приведенную выше классификацию. Если что-то забыл, пишите — будем разбираться;)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность