Исходное сообщение
"Поддержка Rust для ядра Linux столкнулась с критикой Торваль..." Отправлено Аноним, 17-Апр-21 06:34
> чем у регистров на ассемблере надо написать две инструкции: add r1, r1, r2 adc r3, r3, r4 r3 -> mem[x] Казалось бы, что может пойти не так? У апликушника, с 1 тредом - ничего :) А что если в реальной ОС будет, допустим, так? add r1, r1, r2 IRQ <-    something -> mem[x]. IRQ -> adc r3, r3, r4 r3 -> mem[x] Так-так, а мы точно хотели именно это, именно так? Бонус - если обработчик IRQ писан так же, а они еще и разных приоритетов, вышибающих друг друга в произвольное время (так местами можно) можно будет эвона чего откушать. Или: CPU1: add r1, r1, r2 CPU2: something -> mem[x] CPU1: adc r3, r3, r4 CPU1: r3 -> mem[x] При том -> mem[x] для больших типов еще и само по себе не атомарное и IRQ или соседний проц может вклиниться еще и вот туда. А круто когда у вас записалось половина переменной в память, пришел кто-то и сделал что-то, имея в виду совсем не то, потом вон тот неатомарный долелал вторую половину и .. в памяти теперь чего?! Знакомьтесь - race condition. Не очень приятно - особенно дебажить его. Можно конечно атомарные доступы форсануть, но это какой пенальти по перфомансу будет, на минуточку, если надо сделать так чтобы IRQ и другие процессоры точно туда не влезли до того как ВСЕ это сделано? В threaded апликухе вы уже можете некоторые азы прострела пяток выкусить, но в лайтовом варианте.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> чем у регистров на ассемблере надо написать две инструкции: > add r1, r1, r2 > adc r3, r3, r4 > r3 -> mem[x] > Казалось бы, что может пойти не так? У апликушника, с 1 тредом > - ничего :) > А что если в реальной ОС будет, допустим, так? > add r1, r1, r2 > IRQ <- > something -> mem[x]. > IRQ -> > adc r3, r3, r4 > r3 -> mem[x] > Так-так, а мы точно хотели именно это, именно так? Бонус - если > обработчик IRQ писан так же, а они еще и разных приоритетов, > вышибающих друг друга в произвольное время (так местами можно) можно будет > эвона чего откушать. > Или: > CPU1: add r1, r1, r2 > CPU2: something -> mem[x] > CPU1: adc r3, r3, r4 > CPU1: r3 -> mem[x] > При том -> mem[x] для больших типов еще и само по себе > не атомарное и IRQ или соседний проц может вклиниться еще и > вот туда. > А круто когда у вас записалось половина переменной в память, пришел кто-то > и сделал что-то, имея в виду совсем не то, потом вон > тот неатомарный долелал вторую половину и .. в памяти теперь чего?! > Знакомьтесь - race condition. Не очень приятно - особенно дебажить его. > Можно конечно атомарные доступы форсануть, но это какой пенальти по перфомансу будет, > на минуточку, если надо сделать так чтобы IRQ и другие процессоры > точно туда не влезли до того как ВСЕ это сделано? В > threaded апликухе вы уже можете некоторые азы прострела пяток выкусить, но > в лайтовом варианте.
	Введите код, изображенный на картинке: