Собсвтенно сабж.  

Вроде как родных линуксовых средств нету... а в очередной раз изобретать велосипед неохота. 
Подскажити, кто как решает вопрос? 

З.Ы. А если и изобретать велосипед, то только с "блекджеокм и шлюхами", в смысле шобы без блокировок      Возможно ли такое?

изобретают велосипеды. потому как стандартных средств нет :(

Не понял впроса... А чем Вас не устраивает :



Или Вы считаете эти системные вызовы НЕ безопасными ?

svlary, по идее, речь идет об http://cplusplus.com/reference/stl/queue/

Возможно, но очень сложно (смотри lock-free queue, реализовать можно на основе односвязного списка). А зачем тебе?


В интернете полно бесплатных библиотек, бери любую.

Это сообщение отредактировал(а) azesmcar - 29.7.2011, 08:35

Потому как очередь будет активно пользоваться в n-ом количестве потоков. 
И как-то не кошерно  получается,  что для вставки одного единственно элемента (в начало очереди) - приходится блокировать всю очередь, и не только вставка нового элемента становится на паузу,  но и чтение тоже, а ведь оно происходит с конца - эти два процесса теоретически друг другу не должны мешать. А еще хотелось бы, чтобы два и более процессов в случае одновременного чтения могли получить корректные данные, и также не блокировали друг друга. Ведь в большинстве случаев не важно в каком порядке они это сделают. Т.е. допустим что в очереди хранится элементы  A,B,C и допустим два потока пытаются одновременно читать из нее. И не важно прочитает ли первый процесс А а второй B, или наоборот - первому достанется B а второму A. Главное чтобы ни кто не прочитал С или вообще какой-нить XYz       Где-то также дела будут обстоять и с записью.  

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

Эх, мутекс в помощ да велосипед в придачу.. 

Если это действительно актуально (т.е. тебе это нужно не для успокоение совести, а задаче реально нужна высокая масштабируемость), то у тебя несколько вариантов.
1. reader-writer блокировки
2. lock-free
описание и того и другого можно найти по ссылке у меня в подписи.
Следует прогнать под профайлером и посмотреть на что в основном тратиться время и какое решение в твоем случае даст лучший результат. 
В общем сказать можно много чего, но мне как-то лень переписывать тоже самое  
просто перечитай эти две статьи
http://www.data-race.com/2011/02/01/reader...B2%D0%BA%D0%B8/
http://www.data-race.com/2011/02/04/lock-f...eaders-writers/


C++ тоже ничего не гарантирует по поводу атомарности.


Это сообщение отредактировал(а) azesmcar - 29.7.2011, 10:14

Но ведь там написано :



Я это понимаю так, что если в качестве контейнера использовать НАДЕЖНУЮ вещь типа системных FIFO сокетов, то и проблем не будет.  А если городить собственные городушки с мьютексами и прочими семафорами - то и получайте по полной программе. 

организуй для каждого потока свой FIFO, зачем с одним заморачиваться ?

azesmcar, 

 именно для ее родимой. Ну я так подумал.... оно того не стоит. Намалюю себе простенькую очередь  =  будет мне счастье  
Это может быть потом, на досуге, поупражняюсь с lock-free операциями, и очередями в частности. Тема реально заинтересовала. За ссылочки спасибо   


svlary,  

Простите не понял, получайте что? 
Ну я конечно понимаю что все функции семейства read\write проходят через системный кеш. Но мне кажется такая конструкция будет в любом случае работать медленнее, нежели самая примитивная самопальная реализация fifo. Реальное и неоспоримое достоинство Вашего метода в том, что он позволяет использовать очередь между отдельными процессами в системе (без лишних заморочек).


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

Ну да, зато не будет простоя в потоках, когда один работает с FIFO а другие 30 потоков ждут доступа.
И я не говорю что данная схема будет потокобезопасной, тут дело в отсутствии простоев.

shara

расскажи о задаче поподробнее.

Вот ещё одна неплохая статья на эту тему

azesmcar, 
Многопоточный ssl-gateway:  с одной стороны (аля внешнее соединение) имеем ssl-соеденение с машиной A, с другой стороны (внутренее) открытое\незащищенное соединение с машиной B. Точки А и В логически соединены между собой gateway'ем

Собсно решил остановиться на такой архитектуре: 
в отдельном потоке вращается epool, который ждет событий на подключение\обслуживание соединений. 
при наступлении онных - раздает задачи (через очередь    ) рабочим потокам
независимые потоки обслуживают ssl-соеденение (рукопожатие\шифровка\расшифровка) и организовывают передачу информации между двумя концами соединения ( А --> В или А <-- B).

С подачи Dem_max   решил каждому потоку выделить в руки по флагу по своей очереди. 
Тут конечно можно использовать lock-free очередь по сценарию (один пишет и один читает) но не охота "попасть в просак" из-за нюансов компилятора и перевода программы с С++ на Си (ибо как по условию задача должна решаться посредством последнего)
Да и думаю небольшие накладные расходы на синхронизацию доступа к очереди ничто по сравнению с тем временем которое потоки будут тратить на организацию ssl


SenkraD
Хороший материал, спасибо 



з.ы. реально на основе собранного в топике материала можно вкурить тему, взять готовую релицацию или склепать свою. 
Чем на досуге и хочу знаться. Думается мне, что в многопоточном программировании реализация lock-free очереди никогда не будет лишней

изврат в действии  

http://forum.vingrad.ru/forum/topic-336344.html

Добавлено через 2 минуты и 17 секунд


 -

http://forum.vingrad.ru/forum/topic-336344.html