Какие возможные подводные камни в реализации lock-free контейнера данных в разделяемой памяти linux на Си?
Для многопоточного и одновременно многопроцессного серверного приложения написанного на чистом Си под линукс требуется реализовать не блокирующий доступ к общей для всех процессов и потоков структуре данных типа хеш-таблица или skip-list с ключем типа int и значением типа указатель так что-бы сам контейнер данных и сами данные были в разделяемой памяти выделенной через mmap или shm_open. Есть ли в работе с разделяемой памятью подводные камни из-за которых такая схема не сработает? для работы с контейнером и данными будут использовать атомарные операции вроде CAS встроенные в gcc.
Меня тоже давно интересует этот вопрос. Сама по себе идея очень привлекательна в плане быстродействия межпроцессорных коммуникаций. Но я не знаю ни одной известной реализации такой возможности. Как будто что-то препятствует этому технически. Вместо этого для коммуникаций типично используют пайпы и сокеты, а для ускорения нагородили sendfile(), splice() и прочие zero-copy механизмы.
mamkaololosha: теоретиГ ты. lock-free не более чем красивое название. по эффективности всегда нужно выбирать. где-то блокировки эффективнее.
Весь lock-free устроен довольно тупо - "пытаемся пока не получится", что не здорово по нагрузке, по производительности.
Такое впечатление, что фраза "free" это как красная тряпка для быка. Фирленс это круто. А то что это нифига не работа с ноутбуком под пальмой у моря - мимо мозгов пропускается.
Лок-фри - это круто потом что "без блокировок". Там блокировки заменяются попытками многочисленными, что для нагрузки на процессор и для конечной скорости совсем не здорово.
В БД комбинируются оба варианта и жесткие блокировки и многочисленные попытки (лок-фри). Причем в том числе и на уровне транзакций тоже есть 2 схемы - блокировка и версионирование (аналог лок-фри). И блокировка транзакций при том требует меньше ресурсов чем версионирование (аналог лок-фри) транзакций
werw: я и скорее всего nirvimel под быстрее понимаем не саму реализацию контейнера локфри/блокировки, а работу многопроцессной программы через разделяемую память со структурой данных таким же образом как в многопоточной программе доступ через общее адресное пространство по умолчанию, не используя для обмена сокеты или пайпы итд.
Сам лок-фри контейнер реализовать я и не берусь, это мне не по зубам, использую реализацию из библиотеки nbds (Concurrency kit еще на примете), только модифицировать для работы в разделяемой памяти. Или вообще прикрутить Redis или Memcached, вот только "голый" лок-фри контейнер выдает 1-15 млн ОП/с на наборе данных с соотношении поиск/запись схожим с моей задачей, а цифры озвученные в бенчмарках этих БД это около сотен тысяч ОП/с.
По поводу многочисленных попыток в лок-фри, я правильно понимаю, что если операции модификации будут в среднем мало конкурировать, то лок-фри реализация будет быстрее чем на блокировках?
aethylic:
> По поводу многочисленных попыток в лок-фри, я правильно понимаю, что если операции модификации будут в среднем мало конкурировать, то лок-фри реализация будет быстрее чем на блокировках?
Серебряной пули нет.
В каждом алгоритме нужно сугубо индивидуально смотреть.
Лок-фри может оказаться даже хуже чем блокировки.
Может и лучше.
Может и так же.
Причем это лучше/хуже имеет зависимость и от вида нагрузки.
lock-free - это не более чем красивое название. Я замечаю, что в современной цивилизации люди очень здорово ведутся на слово free (примеры выше), совершенно не обращая внимание, что у free есть и минусов множество.
Хороший цикл, по нему и познакомился с лок-фри. Вообще после подобных статей и появилось желание избавиться от блокировок (Ну и еще от курса лекций по параллельному программированию https://vk.com/wall-54530371_53817)
Простой
Простой
