Параллельная обработка оболочки: добавление значений

Ошибка в этом вопросе заключается в том, что не существует такой вещи, как "истощение энтропии". (Не в том смысле, что вы исчерпаете энтропию раньше, чем вселенная исчерпает недостаток энтропии, чтобы позволить вам жить в ней.)

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

Linux /dev/urandom использует CSPRNG, который периодически засеивается дополнительной энтропией. Периодическая перезагрузка помогает в случае частичной компрометации машины, в результате которой происходит утечка внутреннего состояния генератора случайных чисел.

Linux's /dev/random использует CSPRNG, который периодически перезаправляется с дополнительной энтропией. (Звучит знакомо?) Linux поддерживает внутренний расчет, который предполагает, что алгоритм CSPRNG сильно сломан и утечка энтропии происходит с большой скоростью, и блокирует /dev/random. Но если вы не доверяете криптовалюте, стоящей за CSPRNG, вы не можете доверять даже тому, что /dev/random дал вам в первую очередь, или практически любой другой криптовалюте, которую вы будете использовать.

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

Единственный риск с /dev/urandom в Linux заключается в том, что он с радостью выдает предсказуемый результат до того, как он был должным образом посеян. Это не является проблемой для повседневного использования на "нормальном" настольном компьютере или сервере, поскольку они сохраняют пул энтропии на диске. Это вызывает беспокойство, если у вас свежеустановленная система или живая система, которая загружается с носителя, доступного только для чтения. (Живая система - это плохое место для генерации долговременных ключей!) Как только система накопит достаточно энтропии, это навсегда.

Если вам нужен взгляд профессионального криптографа на этот вопрос, вы можете прочитать Томаса Порнина или Томаса Хюна.

¹ N битов энтропии требуют 2N вычислений. Если вы генерируете миллиард битов в секунду и начинаете с приличного уровня безопасности в 128 битов, 1 вселенская жизнь дает вам время для генерации примерно одного секстиллиона битов, что составляет 296, комфортно ниже предела.

2
03.05.2019, 19:05
3 ответа

Некоторые вещи, которые вам не хватает:

  • Переменные оболочки хранятся в памяти оболочки; то есть память процесса оболочки.
  • Большинство команд, запускаемых из оболочки выполняются в дочернем процессе (или процессах ). Единственными исключениями являются «встроенные -в команды».
  • Асинхронные команды всегда выполняются в дочернем процессе. — даже если они не запускают никаких программ. Асинхронная команда, которая не запускает никаких программ — это дочерний процесс, который запускает только оболочку. Это известно как «вспомогательная оболочка -».
  • Вообще говоря, процессы не могут изменять память других процессов. В частности, оболочки sub -не могут изменять переменные в основном процессе оболочки. Итак, когда вы произносите appendnum $no &, функция appendnumне может изменять переменную xв основном процессе оболочки.

Вы можете получить что-то похожее на поведение, которое вы пытаетесь получить с помощью этого:

x=TR007.out
> "$x"
appendnum() {
    echo "$1" >> "$x"
}
for no in {0..10}
do
    appendnum $no &
done
wait

Вы получите числа от 0 до 10, записанные в файл TR007.out.

  • Планирование (последовательности )асинхронных процессов не определено. Таким образом, в приведенном выше примере сценария в то время как вы получите числа от 0 до 10, записанные в файл, они могут быть не в порядке.
  • Как вы, возможно, знаете, waitсам по себе (без аргументов )будет ждать всех дочерних процессов.
  • «Независимо от количества задач мое время отклика должно быть одинаковым». Это очень смелое ожидание/просьба. Разумно ли это, зависит от контекста. Если задача является однопоточной -многопоточной вычислительной -интенсивной задачей, и у вас есть три или более (логических )ЦП, тогда да, может быть разумно ожидать, что три задачи будут выполняться параллельно занять немного больше времени, чем один сам по себе. Но если у вас есть четыре логических процессора, совершеннонеразумноожидать выполнения 50 задач за то же время, которое требуется для запуска одного.
  • Я упомянул, что дочерние (асинхронные )процессы работать в ожидаемом порядке. Поскольку они работают одновременно (, то есть параллельно ), их выполнение, вероятно, будет перекрываться. Итак, если мы изменим приведенный выше скрипт, чтобы он выполнял
    appendnum() {
        echo "$1"a >> "$x"
        echo "$1"b >> "$x"
    }
    for no in {1..3}
    do
        appendnum $no &
    done
    , вы можете получить 1a/ 1b/ 2a/ 2b/ 3a/ 3bв файле — или вы можете получить 2a/ 2b/ 1a/ 1b/ 3a/ 3b, или вы можете получить 2a/ 1a/ 2b/ 3a/ 3b/ 1bили хуже. Запись асинхронных процессов в один и тот же файл — плохая идея.

Вероятно, вам следует сделать что-то вроде

for no in {1..3}
do
    task"$no" > file"$no" &
done
wait
cat file1 file2 file3 > combined_result
Другие примечания :
  • $(command)делает то же самое как `command`. Вам следует придерживаться формы $(command).
  • Нет смысла говорить x=`echo $x$num`или x=$(echo $x$num). Просто скажите x="$x$num".
  • Переменные оболочки всегда следует заключать в кавычки. если у вас нет веской причины не делать этого, и вы уверены, что знаете, что делаете. Так что не делайте appendnum $no; делать appendnum "$no"и т. д.
0
27.01.2020, 22:17

Если я вас правильно понял, вы хотите:

  • Запускать задачи параллельно, т.е. в идеале убедитесь, что все они завершаются за время, необходимое для выполнения одной задачи. (это нереально, но мы можем приложить все усилия)
  • Сохранять порядок вывода, даже если некоторые более поздние задачи завершаются раньше некоторых более ранних задач

Имея это в виду, вы можете попробовать следующее:

parallel -k -j10 'sleep {}; echo -n {}' ::: {10..1}

Первая выполняемая задача занимает больше всего времени, но поскольку мы добавили опцию -k, утилита parallelсохранит порядок и в конечном итоге выведет

10987654321

без опции -kвывод инвертируется и появляется по окончании команд

12345678910

Посмотрите руководство, если вам нужна дополнительная информация:https://www.gnu.org/software/parallel/parallel_tutorial.html

1
27.01.2020, 22:17

[responseof(task1),responseof(task2),responseof(task3)]

parsetсоздан для этого:

parset result responseof ::: task1 task2 task3
echo "${result[1]}"

Например,:

parset res seq ::: 3 2 1
echo "${res[1]}"

parsetявляется частью GNU Parallel.

0
27.01.2020, 22:17

Теги

Похожие вопросы