Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь. Понимаю, что вариантов синхронзации может быть множество, но среди этого разнообразия хотелось бы получить самый оптимальный, ведь задача то тривиальная.
Здравствуйте, BioUnit, Вы писали:
BU>Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь.
Здравствуйте, TepMuHyc, Вы писали:
TMH>Здравствуйте, BioUnit, Вы писали:
BU>Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь.
TMH>...Тогда не вектор, а список — у него время добавления/удаления константное. TMH>Вот здесь ( http://www.rsdn.ru/Forum/Message.aspx?mid=27370&only=1
Да, действительно, список лучше.
Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание. Не произойдет ли чего-нибудь непредвиденного?
Здравствуйте, BioUnit, Вы писали:
BU>Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание. Не произойдет ли чего-нибудь непредвиденного?
Общепринято такое делать внутри именованного мутекса (и поиск в очереди кстати тоже)!
Здравствуйте, BioUnit, Вы писали:
BU>Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь. Понимаю, что вариантов синхронзации может быть множество, но среди этого разнообразия хотелось бы получить самый оптимальный, ведь задача то тривиальная.
Встречный вопрос: выбор именно vector для организации этой очереди здесь окончательный?
Удаление элемента из начала вектора даст копирование почти всего содержимого на один эл-т к началу. Это и неоптимально по скорости и заставляет безусловно синхронизировать операции вставки и выемки элемента. Тут гораздо ближе либо deque (queue) либо list. Вопрос синхронизации останется и тут, но сама операция займет меньше времени и, соответственно, время простоя потока в ожидании доступа к очереди тоже сократится.
Здравствуйте, BioUnit, Вы писали:
BU>Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание.
TMH>Не произойдет ли чего-нибудь непредвиденного?
Обязательно произойдет
Но, коль скоро то сообщение это была иллюстрацией работы с семафором, то эта малозначащая деталь была опущена
____________________
God obviously didn't debug, hasn't done any maintenance, and no documentation can be found. Truly amateur work.
Здравствуйте, TepMuHyc, Вы писали:
TMH>Здравствуйте, BioUnit, Вы писали:
BU>Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание.
TMH>Не произойдет ли чего-нибудь непредвиденного? TMH>Обязательно произойдет TMH>Но, коль скоро то сообщение это была иллюстрацией работы с семафором, то эта малозначащая деталь была опущена
Именно эта "малозначащая деталь" меня и беспокоит от начала топика.
Здравствуйте, BioUnit, Вы писали:
BU>Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание. Не произойдет ли чего-нибудь непредвиденного?
Лучше не расчитывать на это. Посмотри, что написали сами разработчики о потокобезопасности:
simultaneous read access to the same container from within separate threads is safe;
simultaneous access to distinct containers (not shared between threads) is safe;
user must provide synchronization for all accesses if any thread may modify shared container.
Здравствуйте, BioUnit, Вы писали:
BU>Именно эта "малозначащая деталь" меня и беспокоит от начала топика.
Закрывать работу со списком мютексом надо ОБЯЗАТЕЛЬНО. Во избежание.
Причем именно мютексом а не Reader-Writer Lock'ом — т.к. и добавление и извлечение
элемента списка изменяет состояние этого списка.
____________________
God obviously didn't debug, hasn't done any maintenance, and no documentation can be found. Truly amateur work.
Здравствуйте, TepMuHyc, Вы писали:
TMH>Здравствуйте, vvaizh, Вы писали:
V>Общепринято такое делать внутри именованного мутекса TMH>А почему именно "именованного"?
да, ошибся, вданном случае неименованный мутекс лучше хранить прямо рядом со списком/вектором..
V>(и поиск в очереди кстати тоже)! TMH>Поиск, простите, в чем ?????
в контэйнере, или вы туда только класть хотите? а не читать?
Здравствуйте, Михаил Можаев, Вы писали:
BU>Но вот вопрос: когда в очереди одно задание, один поток начинает его выбирать, а другой поток в этот момент добавляет очередное задание. Не произойдет ли чего-нибудь непредвиденного?
ММ>Лучше не расчитывать на это. Посмотри, что написали сами разработчики о потокобезопасности:
ММ>Thread-safety for SGI STL: ММ>Thread safety (STLPort):
Именно с этого я и начал свои изыскания. И первично вопрос был как раз о том, как лучше организовать такую синхронизацию.
Видимо все склоняются к неименованному мьютексу...
Здравствуйте, Михаил Можаев, Вы писали:
ММ>Здравствуйте, vvaizh, Вы писали:
TMH>>Поиск, простите, в чем ????? V>в контэйнере, или вы туда только класть хотите? а не читать?
ММ>Чтобы прочитать первый элемент последовательного контейнера поиск не требуется. Или я что-то не понимаю?
Какая разница, чтение лучше тоже в мутекс загнать, даже первого элемента!
Для вектора — обязательно!
Для списка — если будут операции удаления..
А.. ещё вариант, что читать ту будешь точно уже после того как всё заполнено.. тогда действительно всё чисто..
Здравствуйте, BioUnit, Вы писали:
BU>Есть некоторый vector. Один поток добавляет элементы в его конец, а другой — выбирает из головы, т.е. своеобразная очередь.
Здравствуйте, TepMuHyc, Вы писали:
TMH>Здравствуйте, BioUnit, Вы писали:
BU>>Именно эта "малозначащая деталь" меня и беспокоит от начала топика. TMH>Закрывать работу со списком мютексом надо ОБЯЗАТЕЛЬНО. Во избежание. TMH>Причем именно мютексом а не Reader-Writer Lock'ом — т.к. и добавление и извлечение TMH>элемента списка изменяет состояние этого списка.
В случае списка, во избежание падения перфоманса, можно лочить только три элемента — тот который удаляется/вставляется и два его соседа. К остальным элементам доступ на чтение в это время можно разрешать.
Если это очередь — то лучше список. Ибо обращение к элементу означает также его удаление из очереди. Если это один процесс — то лучше юзать Critical Section
- Простите, профессор, не пса, а когда он уже был человеком.
— То-есть он говорил? Это еще не значит быть человеком. (с) Булгаков
Здравствуйте, small_cat, Вы писали:
SC>Здравствуйте, BioUnit, Вы писали:
SC>Если это очередь — то лучше список. Ибо обращение к элементу означает также его удаление из очереди. Если это один процесс — то лучше юзать Critical Section
