Здравствуйте, AndrewVK, Вы писали:
Однопоточный в том смысле, что менять состояние ресурса в любой момент времени может только один поток. Реализация таких компонентов (тем более — на основе готовых примитивов синхронизации) тривиальна
Здравствуйте, AndrewVK, Вы писали:
R>>Однопоточные компоненты не интересно смотреть...
AVK>Он не однопоточный, иначе бы я не предлагал. Или у тебя все, что не lock free однопоточное?
Ну как же не однопоточный? Однопоточный кэш, вокруг каждого метода которого добавлен мьютекс, который фактически сводит многопоточное окружение к однопоточному.
Здравствуйте, remark, Вы писали:
R>Ну как же не однопоточный? Однопоточный кэш, вокруг каждого метода которого добавлен мьютекс, который фактически сводит многопоточное окружение к однопоточному.
RWLock это не мьютекс, это несколько более хитрая конструкция.
... << RSDN@Home 1.2.0 alpha 4 rev. 1464 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
>>Ну как же не однопоточный? Однопоточный кэш, вокруг каждого метода которого добавлен мьютекс, который фактически сводит многопоточное окружение к однопоточному.
AVK>RWLock это не мьютекс, это несколько более хитрая конструкция.
В данном контексте одинаково тривиальная. Однопоточный контейнер с базовой гарантией многопоточности допускает несколько вызовов константных методов. Трансформация мьютекс->rw_мьютекс представляет O(1) сложность — просто смотрим на текущий метод и глядим делает ли он физическую модификацию объекта или нет. Это не делает методы более многопоточными чем они многопоточные у однопоточного контейнера. Не интересно.
Здравствуйте, vf, Вы писали:
vf>Коллеги, возникло непреодолимое желание поделиться своим велосипедом, получить комментарии, может кому пригодится 
Готового на .нет не нашел, вот сделал свое, с пятой попытки.
vf>Основная задача, была сделать tread-safe пул буферов для сервера, первоначально реализовал это дело через lock, скорость работы lock подхода вынудила копать дальше, в сторону Interlocked, потом узал что правильно такой подход называется lock-free, а так же, что часто возникающая проблема в таких алгоритмах называется ABA (я с ней столкнулся в 3-4 попытке).
vf>В процессе работы над пулом и появился ниже приведенный Stack. В последствии, находил ссылки на pdf-ы с алгоритмами LIFO, FIFO, но не разбирался, вероятно там тоже самое. Читал про .нет 4.0, но там, по описанию, алгоритмы основаны на SpinLock, так что возможно мое будет чуть быстрее (хотя и со своими ограничениями)
Тут мои мысли по поводу этой дискуссии. Так же там алгоритм array-based очереди, его можно портировать под C#, но правда он FIFO, а не LIFO, и простого способа переделать его в LIFO я не вижу.
http://www.rsdn.ru/forum/cpp/3730905.1.aspxАвтор: remark
Дата: 10.03.10
Здравствуйте, remark, Вы писали:
R>Добро пожаловать в мир lock-free 
Нет, я бы не вылез на форум, если бы не ваш снобизм. Господи, только начнут работать, так уже прям гуру-гуру. Я вот скромно себя веду — не выеживаюсь, хотя уже с 97 года занимаюсь исключительно лок-фри. У вас ни одной научной работы нет, однако поучить вы рады. Выучить то что написали другие до вас это заслуга маленькая. Эх зло иногда берет, что в закрытой конторе работаю — опять Маркони что нибудь "изобретет". Что вы там изобретаете? — все давно уже пашет в железе. Интелоиды пальцанутые.
"Нормальные герои всегда идут в обход!"
