SOFT FOR YOUДавайте про lock-free всё-таки :)есть у меня одна идейка, гарантированная lock-free очередь на простых принципах, правда с ограничением размера.
Нужно?

SOFT FOR YOU,

https://svn.code.sf.net/p/cl4fpc/code/Containers/lfqueues.pas
есть правда где-то ошибка на x86 c TAtomicInt = UInt64;, найти времени нет, но 32-битная версия пашет как задумано
заправлю потом в бложик описание реализации

тест
https://svn.code.sf.net/p/cl4fpc/code/Containers/test/FreeLockTest.lpr




SOFT FOR YOUА что с ошибками? По прежнему выдаёт эксепшн?
ну если так закрыть конечно нет, но правильно же он от этого не заработает
20945540 ИМХО правильное рассуждение, нужен механизм проверки нахождения элемента в очереди

SOFT FOR YOUkealon(Ruslan),

Код жёсткий :)
Правда, я так и не понял, зачем столько стейтов
всё очень просто, попытаюсь объяснить в блоге как время будет
PS: баг исправил
SOFT FOR YOUПо поводу Exception-ов
Я ничего не закрыл. Я сделал инкремент счётчика при записи FHead.
Эксепшны сыпятся или нет?

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

TestUG не проходит, хотя проработал без сбоев заметно дольше

с заменой 20945254 проходит без проблем вроде как

SOFT FOR YOUkealon(Ruslan),

Спасибо
Конечно интересно почитать блог

Но давай исправим ошибку в моей реализации
А потом замерим производительность :)

Я просто думаю, что контейнеры надо создавать опционально: с лимитированным количеством элементов и нет. Потому как в лимитированных реализациях может быть определённый профит, как с точки зрения функционала, так и с точки зрения производительности.тут всё довольно просто:
исходя из тестов что я знаю на i7: конкурентно в секунду можно провести 40 млн обменных операций с одной кэш-линейкой
т.е. тупо InterlockedIncrement из 4-х и более потоков можно сделать 40млн/c, в один поток - 150млн/c

представленный алгоритм упирается сейчас в 2.5 млн (добавление + удаление) в секунду
твой (пока работает) - упирается в 3.5 млн (добавление + удаление)/c
тут насколько я их понимаю добились - 16 млн. /c, и в явовской - 4 млн./c (проц вроде бы такой же как и у меня, но с другой стороны хз как они тестят, например забитая очередь явно шустрее идёт, чем близкая к нулю)

т.е. ещё оптимизировать и оптимизировать, наверное, первое - это функцию разгрузки
SOFT FOR YOUkealon(Ruslan),

Мне кажется, или у тебя ограничение на количество элементов жёстко - 21?
Кстати DefaultValue можно не хранить, есть "функция" Default(T)
10 и 21, в зависимости от типа (нужно 3 бита на состояние одной ячейки)
Default(T) - в fpc старой версии её добавить не успели

SOFT FOR YOU,

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

соответственно при наличии 2-х операций на вставке, 2-х на удалении это 10млн/c максимум для моего проца

SOFT FOR YOU,

занятную функцию нашёл - WaitOnAddress
по идее для разгрузки самое то

_StarikPro_Народ, разъясните пожалуйста (признаюсь, всю ветку темы ТС не читал), чем не устраивает очередь с кольцевым буфером в котором указатель на тайл читающего и пишущего потоков "не пересекаются " при условии что для обеспечения многопоточности создаём одну очередь на каждую пару потоков??? Соотв-но, к примеру, для одного читающего и N в него пишущих создаём N очередей который опрашивает читающий... При этом отпадает необходимость в применении спец. синхронизирующих системных функций...ситуация: 1 читающий, много пишущих - не самая распространённая
одну очередь проще использовать, она становистя слабым местом систем типа акторов, например


вот все и меряются ...

SOFT FOR YOUkealon(Ruslan),

Так он под Windows 8
Лучше тогда уж вручную брейкпоинт на память делатьи в каком потоке он вызовется?

SOFT FOR YOU,

TestUG падает