w2k+
Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)
Re: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, greenloki, Вы писали:
G>w2k+ G>Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)
Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.
Re: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, greenloki, Вы писали:
G>w2k+ G>Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)
См. boost::read_write_mutex.
Re: синхронизация: 1-2 писателя и множество читателей
greenloki wrote:
> w2k+ > Интересует внутрипроцессная синхронизация между большим количеством > потоков читателей и 1-2 редкими потоками писателями, но не между > читателями. То есть потоки читатели не должны блокировать друг друга, > блокировка читателей возможна только при записи, блокировка писателей > возможна при чтении. Я так представляю будут использоваться критические > секции или семафоры (мне всё равно, но желательно более быстрый способ > для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, > можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к > обычному std::vector) > синхронизация: 1-2 писателя и множество читателей <?mid=1878385>
What are sequence locks (seqlock_t)
– Similar to reader-writer spin locks
– But favor writers over readers
– A writer accesses data after acquiring a lock, while readers check the
lock by polling the sequence count
• Read needs retry if the count differs or it is an odd number
-- Maxim Yegorushkin
Posted via RSDN NNTP Server 2.0
Re[2]: синхронизация: 1-2 писателя и множество читателей
А>Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.
спасибо! попробую
Re[2]: синхронизация: 1-2 писателя и множество читателей
DK>См. boost::read_write_mutex.
до буста я пока не добрался ещё как повлияет на размер экзешника если я всё таки попробую подключить буст и использовать этот метод?
Re[2]: синхронизация: 1-2 писателя и множество читателей
Ну тебе не угодишь...
То буст большой, то самому что-то делать.
Подключение буста, кстати, не сильно скажется на твоем экзешнике.
Ну ни сильней, чем ты все сам ручками аккуратно будешь делать.
Re[2]: синхронизация: 1-2 писателя и множество читателей
От:
Аноним
Дата:
04.05.06 07:05
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.
Писатель еще должен дождаться, что текущие читатели все дочитали
и заблокировать на время записи всех других писателей/читателей.
В общем в таких вещах лучше довериться проверенным решениям,
если конечно нету цели набить шишки самому в целях обучения.
Re[2]: синхронизация: 1-2 писателя и множество читателей
Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.
Но если операции модификации/доступа быстрые (что часто и бывает), то конкуренция за ресурс может быть невысокой, тогда и обычный мьютекс подойдет. Этот факт также свидетельствует о том, что в такой ситуации критические секции не дадут выигрыша в скорости, т.к., если мьютекс свободен, то WaitForSingleObject вернет управление, не переходя в режим ядра.
Re[3]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, Dmitry Kotlyarov, Вы писали:
DK>>См. boost::read_write_mutex.
DK>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.
А можно вкратце почему? Какого типа проблемы возникали?
Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.
Re[4]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, MaximE, Вы писали:
ME>>>Используй sequence lock. ME>>>http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20Kernel%20Synchronization.pdf
G>>а как это соотносится с требованием w2k+?, или ты предлагаешь отложить всё и занятся их реализацией под винду
ME>Копируешь код из хедера линукс. Изменяешь gnu asm на vc asm, работы на час.
Не забываешь изменить лицензию своего кода на GPL
Re[4]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, Посторонним В., Вы писали:
ПВ>Здравствуйте, Dmitry Kotlyarov, Вы писали:
DK>>>См. boost::read_write_mutex. DK>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.
ПВ>А можно вкратце почему? Какого типа проблемы возникали? ПВ>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.
Хм, что, никто не знает?
Re[5]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, Посторонним В., Вы писали:
ПВ>Здравствуйте, Посторонним В., Вы писали:
ПВ>>Здравствуйте, Dmitry Kotlyarov, Вы писали:
DK>>>>См. boost::read_write_mutex. DK>>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.
ПВ>>А можно вкратце почему? Какого типа проблемы возникали? ПВ>>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.
ПВ>Хм, что, никто не знает?
Я не слыхал ничего плохого об rw мьютексах.
Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.
Re[6]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, MaximE, Вы писали:
ME>Здравствуйте, Посторонним В., Вы писали:
DK>>>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.
ПВ>>>А можно вкратце почему? Какого типа проблемы возникали? ПВ>>>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.
ПВ>>Хм, что, никто не знает?
ME>Я не слыхал ничего плохого об rw мьютексах.
ME>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.
Я бы не стал так уж хоронить виндозу тока потому что она не соответствует POSIX. Не потому что она мне нравится, а потому что ей пренадлежит приличная часть рынка и с этим надо как-то жить
А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix?
Re[7]: синхронизация: 1-2 писателя и множество читателей
[]
ME>>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.
ПВ>Я бы не стал так уж хоронить виндозу тока потому что она не соответствует POSIX. Не потому что она мне нравится, а потому что ей пренадлежит приличная часть рынка и с этим надо как-то жить
Не нужно с этим жить. Мое мнение.
ПВ>А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix?
Не смогу посоветовать. Я доволен тем, что предоставляет POSIX.
Re[8]: синхронизация: 1-2 писателя и множество читателей
Здравствуйте, MaximE, Вы писали:
ME>Здравствуйте, Посторонним В., Вы писали: ME>>>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса. ПВ>>А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix? ME>Не смогу посоветовать. Я доволен тем, что предоставляет POSIX.
Реализация POSIX для Win32 тоже предоставляет rw locks. Непонятно только зачем в бусте хотели ее еще раз переделать.
как повлияет на размер экзешника если я всё таки попробую подключить буст и использовать этот метод?
