Потёртая система с торчащими нитями

[andrzejn]

Одноядерные процессоры в персональных компьютерах морально устарели. Они останутся живы-здоровы в специальных устройствах, они ещё послужат лет двадцать в старых машинах, пока те не вымрут своей смертью, но впредь производительность настольных и карманных систем будет расти в основном за счёт параллелизма.

Сейчас мы пожинаем плоды переходного процесса.

Операционные системы освоили многозадачность ещё на древних одноядерных процессорах (даже без приставки микро-). Для пользователя процессы шли параллельно, но глубоко внутри царило жульничество: потоки просто делились на крошечные кусочки, которые смешивались в общую очередь и исполнялись по порядку. Это почти как настоящий параллелизм, но не совсем: в каждый момент времени исполняется только один поток.

Некоторых программистов это расслабляло, и они программировали многозадачность небрежно. Когда в массовое производство пошли многоядерные системы, это аукнулось. Так, я видел одну экзотическую Java-машину, которая на процессоре с гипертридингом изредка роняла весь компьютер в перезагрузку.

Теперь большинство разработчиков (у кого работодатели не жадные) работают минимум на двухъядерных рабочих станциях. Тут уже всякая небрежность синхронизации быстро вылазит на глаза глюками и зависаниями. Поэтому все нормальные программисты теперь учитывают реальный параллелизм.

Зато их программы начали блокироваться и глючить на одноядерных системах.

З-заразы.

Comments

[shet.livejournal.com]

Очень интересная тема. А можно пару примеров на пальцах: того что хорошо работает на одном ядре и плохо на двух, и наоборот? Я-то до это наивно думал, что бывает просто правильно и неправильно написанный мультитрэд...

[andrzejn]

Именно. Правильно написанный мультитрэд хорошо работает везде, а неправильно написанный - только там, где тестировали.

Из ярких примеров "хорошо на одном, плохо на двух" у меня только эта самая несановская Java-машина. Остальное - мелкие глюки с перерисовками интерфейса, конкретные примеры даже и не запоминал.

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

[ban-dana.livejournal.com]

Поймете - расскажите, очень интересно.
Потому что, когда хорошо на одном и плохо на двух - это понятно, это вероятность race растет. А вот наоборот - это уже не понятно, потому что виснет - это, по идее, дедлок; но для дедлока нужна блокировка, а она работает и на мультиядре, т.е. там тоже должно виснуть...

[andrzejn]

Наша дежурная гипотеза: какой-то поток временно поднимает себе приоритет и блокируется на синхронизации с низкоприоритетным потоком. На двухъядерном процессоре низкоприоритетный поток отрабатывает на втором ядре и отпускает блокировку, а на одноядерном планировщик не выдаёт время низкоприоритетным потокам, пока высокоприоритетный хочет работать.

Хотя, по идее, ожидание на семафоре или Sleep должны бы пускать поработать и низкоприоритетные потоки, тупого же зацикливания у нас нету - процессор свободен...

[al-zatv.livejournal.com]

вапче-та крутые учёные придумывают всё новые и новые виды транзисторов. Вот как придумают что-нибудь революционное - пойдут тридцатитрёхгигагерцовые процессоры) На неотработанных технологиях делать несолько ядер - дорого выходит из-за вероятности брака.

А так как все к тому времени уже привыкнут к многоядерным процам, новые процы будут их аппаратно имитировать:))))

[andrzejn]

Ничего, скоро упрутся в ограничения по количеству и быстродействию атомов.

[livelight]

> программировали многозадачность небрежно

Что значит "программировали многозадачность"? Писали реализацию спинлоков и семафоров? А кто такой экзотикой занимается, кроме авторов виртуальных машин и операционок?

[livelight]

Тогда ученые изобретут новые атомы :))

[andrzejn]

Некоторые и реализации писали. Те же авторы Java-машины.

А остальные просто не ставили синхронизации везде, где нужно - мол, пока я читаю и инкрементирую переменную, никто другой её не тронет.

[livelight]

А как же инверсия приоритетов? Нормальный планировщик, если высокоприоритетный процесс ждет низкоприоритетного, разгоняет тот низкоприоритетный, чтобы высокоприоритетный дождался блокировки побыстрее. Не говоря уж о том, что нормальный планировщик (кроме специальных случаев) должен иногда пускать поработать хоть немного всех.

[andrzejn]

Прояснили. Обработчик event'а приходил исполняться в наполовину уничтоженный Dispose'ом объект, и от этого что-то там внутри рушилось. (Это всё под .NET 2.0.)

Не стали разбираться дальше, просто исправили изначально некорректную отправку event'а.

[shet.livejournal.com]

Забавно. "У нас в поликлинике был такой похожий случай". Обработчику очереди событий приходило событие "прекратить работу" и в процессе разбора этого события (собственно обработчик dispose-ился) обработчик успевал принять в себя следующее из очереди из-за чего всё было плохо. Только проявлялось уже на 2-ядерной машине, вот я про него и не вспомнил.

[andrzejn]

Выяснили. Приоритеты не виноваты.

[ban-dana.livejournal.com]

А, тогда да.

[livelight]

В старом добром C++ в таких случаях мне иногда счастливилось получать Pure virtual function called :)