Здравствуйте, 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

Здравствуйте, greenloki, Вы писали:

G>w2k+
G>Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)

Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.

Здравствуйте, greenloki, Вы писали:

ME>>Используй sequence lock.
ME>>http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20Kernel%20Synchronization.pdf
G>а как это соотносится с требованием w2k+?, или ты предлагаешь отложить всё и занятся их реализацией под винду

Копируешь код из хедера линукс. Изменяешь gnu asm на vc asm, работы на час.

Здравствуйте, greenloki, Вы писали:

ME>>Используй sequence lock.
ME>>http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20Kernel%20Synchronization.pdf
G>а как это соотносится с требованием w2k+?, или ты предлагаешь отложить всё и занятся их реализацией под винду

Ну тебе не угодишь...
То буст большой, то самому что-то делать.

Подключение буста, кстати, не сильно скажется на твоем экзешнике.
Ну ни сильней, чем ты все сам ручками аккуратно будешь делать.

w2k+
Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)

Здравствуйте, greenloki, Вы писали:

G>w2k+
G>Интересует внутрипроцессная синхронизация между большим количеством потоков читателей и 1-2 редкими потоками писателями, но не между читателями. То есть потоки читатели не должны блокировать друг друга, блокировка читателей возможна только при записи, блокировка писателей возможна при чтении. Я так представляю будут использоваться критические секции или семафоры (мне всё равно, но желательно более быстрый способ для читателей), плюс возможно также класс хелпер. Подскажите хоть идею, можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к обычному std::vector)


См. boost::read_write_mutex.

Lock-free хранилище

Автор: remark
Дата: 16.04.06

greenloki wrote:

> w2k+
> Интересует внутрипроцессная синхронизация между большим количеством
> потоков читателей и 1-2 редкими потоками писателями, но не между
> читателями. То есть потоки читатели не должны блокировать друг друга,
> блокировка читателей возможна только при записи, блокировка писателей
> возможна при чтении. Я так представляю будут использоваться критические
> секции или семафоры (мне всё равно, но желательно более быстрый способ
> для читателей), плюс возможно также класс хелпер. Подскажите хоть идею,
> можно в псевдокоде. (что-нибудь простое, я синхронизирую доступ к
> обычному std::vector)
> синхронизация: 1-2 писателя и множество читателей <?mid=1878385>

Используй sequence lock.
http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20Kernel%20Synchronization.pdf

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

А>Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.
спасибо! попробую

DK>См. boost::read_write_mutex.
до буста я пока не добрался ещё как повлияет на размер экзешника если я всё таки попробую подключить буст и использовать этот метод?

RO>Lock-free хранилище

Автор: remark
Дата: 16.04.06

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

ME>Используй sequence lock.
ME>http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20Kernel%20Synchronization.pdf
а как это соотносится с требованием w2k+?, или ты предлагаешь отложить всё и занятся их реализацией под винду

Здравствуйте, Аноним, Вы писали:

А>Ну событиями можно — надо только одно событие записи. Т.е. примерно это выглядит так: читатель ждет освобождения события записи, потом читает, писатель также ждет освобождения собития записи (чтобы не перетереть других писателей), после этого сразу занимает событие записи — пишет, осбождает событие.

Писатель еще должен дождаться, что текущие читатели все дочитали
и заблокировать на время записи всех других писателей/читателей.

В общем в таких вещах лучше довериться проверенным решениям,
если конечно нету цели набить шишки самому в целях обучения.

DK>См. boost::read_write_mutex.


Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.

Но если операции модификации/доступа быстрые (что часто и бывает), то конкуренция за ресурс может быть невысокой, тогда и обычный мьютекс подойдет. Этот факт также свидетельствует о том, что в такой ситуации критические секции не дадут выигрыша в скорости, т.к., если мьютекс свободен, то WaitForSingleObject вернет управление, не переходя в режим ядра.

Здравствуйте, Dmitry Kotlyarov, Вы писали:

DK>>См. boost::read_write_mutex.


DK>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.

А можно вкратце почему? Какого типа проблемы возникали?
Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.

Здравствуйте, Посторонним В., Вы писали:

ПВ>Здравствуйте, Dmitry Kotlyarov, Вы писали:

DK>>>См. boost::read_write_mutex.
DK>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.

ПВ>А можно вкратце почему? Какого типа проблемы возникали?
ПВ>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.

Хм, что, никто не знает?

Здравствуйте, Посторонним В., Вы писали:

ПВ>Здравствуйте, Посторонним В., Вы писали:

ПВ>>Здравствуйте, Dmitry Kotlyarov, Вы писали:

DK>>>>См. boost::read_write_mutex.
DK>>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.

ПВ>>А можно вкратце почему? Какого типа проблемы возникали?
ПВ>>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.

ПВ>Хм, что, никто не знает?

Я не слыхал ничего плохого об rw мьютексах.

Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.

Здравствуйте, MaximE, Вы писали:

ME>Здравствуйте, Посторонним В., Вы писали:

DK>>>>Извини, поторопился: boost::read_write_mutex убрали, т.к. он приводил к deadlock-ам.

ПВ>>>А можно вкратце почему? Какого типа проблемы возникали?
ПВ>>>Я к тому что уже где-то слышал, что RW мутексы — это не очень хорошо, хотелось бы узнать почему же.

ПВ>>Хм, что, никто не знает?

ME>Я не слыхал ничего плохого об rw мьютексах.

ME>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.

Я бы не стал так уж хоронить виндозу тока потому что она не соответствует POSIX. Не потому что она мне нравится, а потому что ей пренадлежит приличная часть рынка и с этим надо как-то жить

А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix?

Здравствуйте, Посторонним В., Вы писали:

[]

ME>>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.

ПВ>Я бы не стал так уж хоронить виндозу тока потому что она не соответствует POSIX. Не потому что она мне нравится, а потому что ей пренадлежит приличная часть рынка и с этим надо как-то жить

Не нужно с этим жить. Мое мнение.

ПВ>А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix?

Не смогу посоветовать. Я доволен тем, что предоставляет POSIX.

Здравствуйте, MaximE, Вы писали:

ME>Здравствуйте, Посторонним В., Вы писали:
ME>>>Современные POSIX реализации предоставляют такой мьютекс, legacy же платформы, как виндоза, к примеру, не имеют такого мьютекса, поэтому в бусте была некачественная самопальная реализация такого мьютекса.
ПВ>>А может посоветуешь какие есть нормальные реализации rw lock-ов для Windows и Linix?
ME>Не смогу посоветовать. Я доволен тем, что предоставляет POSIX.

Реализация POSIX для Win32 тоже предоставляет rw locks. Непонятно только зачем в бусте хотели ее еще раз переделать.