The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Поддержка Rust для ядра Linux столкнулась с критикой Торвальдса, opennews (ok), 15-Апр-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


396. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от BSA (?), 16-Апр-21, 09:21 
Проблем с большими типами вообще быть не должно. Если целевая платформа их нативно не поддерживается, то создается или библиотечный вызов, или эмуляция в месте использования. Просто то, что на языке высокого уровня это сделать сложней, например для сложения двух чисел разрядностью в 2 раза большей, чем у регистров на ассемблере надо написать две инструкции: add r1, r1, r2 и adc r3, r3, r4. А теперь попробуйте сложение с учетом переноса сделать на любимом языке высокого уровня...
Ответить | Правка | К родителю #369 | Наверх | Cообщить модератору

441. "Поддержка Rust для ядра Linux столкнулась с критикой Торваль..."  +/
Сообщение от Анонимъ (?), 16-Апр-21, 16:53 
Аналога adc может не быть на некоторых архитектурах.
Ответить | Правка | Наверх | Cообщить модератору

459. "Поддержка 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 апликухе вы уже можете некоторые азы прострела пяток выкусить, но в лайтовом варианте.

Ответить | Правка | К родителю #396 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру