Как правильно сделать синхронизацию массива между pthread'ами?

reader/writer lock?

правильный ответ - Erlang

капча: function axcha

> Карта типа unsigned char[] изменяется за один раз (одно сообщение) - на один байт (x,y).


Если у тебя гаранитрованно маленькое количество изменений за один игровой тик - тебе вообще не нужны три карты тебе нужна одна, а изменения надо вносить на обработке тика.

гугли про readers/writers problem

Хм. Следует на каждой итерации в каждом треде делать pthread_rwlock_ (она есть не всегда, но ее можно либо самому реализовать либо откуда-то вытащить, вообще просто реализуется через pthread_mutex и pthread_cond)

Главное чтобы потоки не спали удерживая блокировку.

Тогда получается расшаренная карта которая будет довольно быстро реагировать на события.

То есть, на время записи/чтения - блокировать потоки через mutex'ы?

> тебе вообще не нужны три карты тебе нужна одна, а изменения надо вносить на обработке тика.

Про тик - не понял. А карта - одна, на все три нити.
И так - у каждого процесса-клиента.

Сервер -> Клиент, Клиент, ... Клиент

Почти ;) Суть в том что если блокировать через мьютекс то все нити будут ждать его независимо от того - читают они карту или меняют.

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

Работает так - много потоков могут иметь одновременно доступ на чтение, при этом никто не может писать. Либо кто-то один пишет, но никто не может читать.

Если обновления приходят очень часто, то изменяющий поток может их накапливать на своей копии карты, и раз в N секунд (или когда изменено более 10% карты) синхронизировать ее с основной версией карты.

> Про тик - не понял.

Плохо. У тебя же игра, нет? Погугли геймтик.

> Если обновления приходят очень часто,

А если - не очень часто? Блокировку можно не делать?
То есть - результат записи в массив (не объявленный volatile) из одной нити -
сразу будет виден в других нитях, не кэшируясь процессором?
У меня обновления на карте происходят (посылаются через MQ) с частотой от 2 до 10 Герц.

> Плохо. У тебя же игра, нет?

Да, игра.

Погугли геймтик

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

Собираюсь делать частоту проверок на «коллизии» примерно в 2-3 раза
большей, чем частота «шагов» объектов игры. На один шаг каждого
персонажа-объекта может убираться один объект с карты (write) (он его
«съедает»). Поэтому такой частоты проверки карты (read) будет достаточно.

> Собираюсь делать частоту проверок на «коллизии» примерно в 2-3 раза
большей, чем частота «шагов» объектов игры.

Это же бессмысленно.

> Это же бессмысленно.

Просто два игрока - поэтому «совокупная» их частота движения будет -
в два раза большей частоты шагов одного игрока. И - примерно равной
частоте проверок на коллизии. Интуиция мне подсказывает, что ее надо
сделать чуть выше. Строго все это я не доказываю - времени нету,
так как - шабашка для студента.

> - поэтому «совокупная» их частота движения будет - в два раза большей частоты шагов одного игрока.

Это ошибка в реализации игровой логики. Частота движения игроков должна быть равна игровому тику.

нет, блокировку надо всегда делать, про часто/нечасто - этоя про оптимизацию.

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

> Частота движения игроков должна быть равна игровому тику.

В моей системе понятие «игровой тик» отсутствует, так как события
от игроков приходят асинхронно, но - с равной частотой. Эти события
могут быть «сдвинуты» друг относительно друга на небольшую дельту.
Поэтому «тики» от игроков могут приходить с любым интервалом,
«плавать» друг относительно друга, теоретически.

> и одновременно одна будет читать то чтот ы наполовину переписал.

Там всего один байт записывается.

Байт наполовину прочитать нельзя.

Заметь, что ты читаешь всю карту за раз. Тебе говорят о том, что блокировку надо ставить не на один байт, а на весь массив. А так как у тебя (сказано тобой выше) асинхронно всё происходит, то тебе надо блокировать на время изменения ВЕСЬ массив (в конце концов, ты же не знаешь кому какой кусок карты нужен будет в тот или иной момент времни (если уж оптимизировать по области «видимости» карты игроком), а кто будет какой кусок карты изменять). Не зацикливайся на «почти одновременно», «с равной частотой» Это сферические треды в вакуумной операционке будут работать с равной частотой (пусть гуру поправят, если я что путаю). Volatile тебе тоже не поможет, как выше сказали уже, процессор тут ни при чем. Один из хороших вариантов подсказал г-н OxiD про блокировку на запись одним, блокируя чтение всем, и разрешать читать всем

> асинхронно, но - с равной частотой.

Это - оксюморон. Погугли, что такое (а-)синхронно.

события от игроков приходят асинхронно, но - с равной частотой. Эти события могут быть «сдвинуты» друг относительно друга на небольшую дельту. Поэтому «тики» от игроков могут приходить с любым интервалом, «плавать» друг относительно друга

При синхронной обработке это не имеет значения.

LamerOk:

асинхронно, но - с равной частотой.

Это - оксюморон. Погугли, что такое (а-)синхронно.

а - частица отрицания
синхронно - одновременно

Я под этим понимаю неодновременность «ожидания» пакета (сообщения),
и - его фактического прихода [адресату].

У простите бывшего математика за такую вольность в терминологии.

BrotherWarrior:

Заметь, что ты читаешь всю карту за раз.

«Читающие» нити к ней обращаются постоянно.

Тебе говорят о том, что блокировку надо ставить не на один байт, а на весь массив.

А зачем вообще тут нужна блокировка?
Ведь запись/чтение байта - атомарно.
Я, конечно, могу «тормозить» mutex'ами нити на время записи/чтения (этот принцип еще помещается в мою голову).
Но зачем это делать - мне непонятно.
Разве изменение в одном байте одной нитью не будет доступно другим нитям (thread'ам) на чтение, сразу же?

в конце концов, ты же не знаешь кому какой кусок карты нужен будет

в тот или иной момент времни

В один промежуток времени (раз в пол-секунды - 1/4 секунды) - обнуляется одна клеточка карты.

Зачем вешать блокировку на чтение карты (часть карты)? Не могу понять.

Вообщем, уже нашел место, в котором блокировка на чтение нужна:
когда один поток меняет сразу две глобальные переменные: dx,dy для игрока (его направление движения).
Поток «рисования» не должен прочитать новые значения «наполовину».
Для этого и буду использовать рекомендации, высказанные ONIX'ом.

если это всего 2 переменные, то лучше использовать что-то основанное на spinlock ах мне кажется, все таки мьютексы это переход в ядро, будет довольно медленно.

> если это всего 2 переменные, то лучше использовать что-то основанное на spinlock ах мне кажется,

Там будет немножко больше двух переменных. Пока сложно сказать - сколько, так как проект клепается на коленке без ТЗ (и - в сжатые сроки).

Всем спасибо, буду копать дальше.

> все таки мьютексы это переход в ядро

4.2