The OpenNET Project / Index page

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

Решение проблем с блокировками изменения данных для систем с большим числом CPU

28.05.2008 11:33

Клиф Клик (Cliff Click) из компании Azul Systems предложил интересное решение проблемы по обеспечению работы быстрых и надежных блокировок при изменении структур данных в системах с большим количеством процессоров. При числе процессоров превышающих 32 становится неэффективным использование стандартных механизмов блокировки доступа к общим данными из многопоточных программ. Клифу была поставлена задача найти решение данной проблемы для 768-ядерной системы (теоретический порог возможности использования read-write локов - 50-100 CPU).

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

В рамках проекта high-scale-lib разработана Java библиотека с реализацией предложенного подхода. Так реализация хэша (java.util.concurrent.ConcurrentHashMap) на 768 ядерной системе позволяет обрабатывать более миллиарда чтений данных в секунду при более 10 миллионов изменений в секунду (подход эффективен когда интенсивность чтения преобладает над изменением).

  1. Главная ссылка к новости (http://www.infoq.com/news/2008...)
  2. Видео с пояснением работы алгоритма
  3. Текст презентации с конференции JavaOne
Лицензия: CC BY 3.0
Источник: slashdot.org
Короткая ссылка: https://opennet.ru/16138-lock
Ключевые слова: lock, thread, cpu, gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (7) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, pazke (?), 12:36, 28/05/2008 [ответить]  
  • +/
    Это только мне кажется что Клиф Клик заново изобрел RCU ? http://en.wikipedia.org/wiki/Read-copy-update

    А то английская статья несколько мутновата, а текст новости похоже вообще промптом переводили :(

     
     
  • 2.7, smb (?), 21:08, 28/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    RCU не license-free, AFAIK.

    Фиг знает на что похоже. надо серьезно курнуть. Если идея, выраженная в ньюсе по-русски как "чтение + инкременальное обновление", то вроде схоже.

     

  • 1.3, Аноним (-), 13:40, 28/05/2008 [ответить]  
  • +/
    >а текст новости похоже вообще промптом переводили :(

    А тут процентов 90 новостей оставляют впечатление promt-translated :E

     
  • 1.4, Ананимус (?), 14:40, 28/05/2008 [ответить]  
  • +/
    Ничего не понял, поясните плз
     
  • 1.6, pavlinux (ok), 17:26, 28/05/2008 [ответить]  
  • +/
    Что-то, кажется, для реализации алгоритма конечного автомата на 768 CPU понадобится 768! - ячеечный массив. У кого есть GMP калькулятор, сколько это?
     
     
  • 2.9, gvf (??), 23:35, 28/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    768! грубо равно 7*10^1882
     

  • 1.10, Аноним (10), 03:05, 29/05/2008 [ответить]  
  • +/
    >RCU ? http://en.wikipedia.org/wiki/Read-copy-update

    Хмм ... очень похоже на блокировочник vs версионник в RDBM области ....
    До чего Ё! дошёл прогресс! :-)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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