Клиф Клик (Cliff Click) из компании Azul Systems предложил интересное (http://www.infoq.com/news/2008/05/click_non_blocking) решение проблемы с обеспечением быстрых и надежных блокировок при изменении структур данных в системах с большим количеством процессоров. При числе процессоров превышающих 32 становится неэффективным использование стандартных механизмов блокировки доступа к общим данными из многопоточных программ. Клифу была поставлена задача найти решение данной проблемы для 768-ядерной системы (теоретический порог возможности использования read-write локов - 50-100 CPU).
Суть идеи в изменении стиля кодирования и вовлечения для хранения данных массива большого размера, изменение каждой ячейки которого является атомарной операцией, а для переключения активной позиции в массиве и логической репликации единицы данных используется алгоритм работы конечного автомата (http://ru.wikipedia.org/wiki/%D0%9A%D0%B......URL: http://www.infoq.com/news/2008/05/click_non_blocking
Новость: http://www.opennet.me/opennews/art.shtml?num=16138
Это только мне кажется что Клиф Клик заново изобрел RCU ? http://en.wikipedia.org/wiki/Read-copy-updateА то английская статья несколько мутновата, а текст новости похоже вообще промптом переводили :(
RCU не license-free, AFAIK.Фиг знает на что похоже. надо серьезно курнуть. Если идея, выраженная в ньюсе по-русски как "чтение + инкременальное обновление", то вроде схоже.
>а текст новости похоже вообще промптом переводили :(А тут процентов 90 новостей оставляют впечатление promt-translated :E
Ничего не понял, поясните плз
Что-то, кажется, для реализации алгоритма конечного автомата на 768 CPU понадобится 768! - ячеечный массив. У кого есть GMP калькулятор, сколько это?
768! грубо равно 7*10^1882
>RCU ? http://en.wikipedia.org/wiki/Read-copy-updateХмм ... очень похоже на блокировочник vs версионник в RDBM области ....
До чего Ё! дошёл прогресс! :-)