AtomicData или механизм атомарной операции записи данных

[m_ax]

Мне кажется тема зашла в тупик, на мой взгляд гораздо лучше/полезнее было бы обсудить вот это

В смысле, можно создать внутренний буфер (массив тобиш). Пока читатели читают из одной ячейки массива, писатель, чтоб не простаивать пишет в следующую, и после того как запишет устанавливает индекс для чтения с актуальными данными. При этом в следующий раз писатель будет выбирать новый индекс для записи с учётом того, откуда читают данные читатели. Короче, читатели всегда будут знать где актуальные даные, а писатели будут знать куда писать, чтобы не было простоев.

Конечно в новой теме

Давайте создадим, как предлагаете назвать? И ещё для этого, если использовать только абстрактные rwlocker нужно мне бы хотелось знать логику их работы. 

[Igors]

2й тред будет иметь в стеке nn == 2 и получит право на лок, как только level станет 2

Вы правы 

А что такое scoped_lock ? И как он устроен?

хороший пример QMutexLocker (пасется на деструкторе, поэтому scoped)

И ещё для этого, если использовать только абстрактные rwlocker нужно мне бы хотелось знать логику их работы. 

Ну об этом было много сказано выше  "Read-write" - название неточное, строго говоря, "shared-exclusive". То есть захват может быть или многими нитками (shared) или только одной (exclusive). Это может быть чтение-запись, но не только

Нет, не зависнет он навсегда, поскольку key-- будет только тогда, когда tmp > 0

но ведь возможно что tmp > 0, а key уже -1, тогда после key-- он станет -2 (с печальными последствиями)

Давайте создадим, как предлагаете назвать?

Ну давайте я создам используя цитату Вашего поста - не возражаете ?

[brankovic]

хотел написать, но Igors уже всё сказал. Добавлю, что scoped_lock очень важная вещь, в рабочем коде обычный mutex::lock () вообще лучше не использовать, так что рекомендую ознакомиться.

[m_ax]

Ну давайте я создам используя цитату Вашего поста - не возражаете ?

Не возражаю)

Ну об этом было много сказано выше  Улыбающийся "Read-write" - название неточное, строго говоря, "shared-exclusive". То есть захват может быть или многими нитками (shared) или только одной (exclusive). Это может быть чтение-запись, но не только

Мне интересно следующее: Пусть писатель W1 пишет данные, приходят ещё несколько писателей. Пока они ждут своей очереди. Теперь приходит читатель R1, читать пока запрещено, пока W1 пишет. Вопрос, когда будет разрешено читать R1? Когда допишет текущий W1 или пока допишут все писатели, что заявили о себе до прихода R1?
Аналогичный вопрос, но с ситуацией, когда изначально читали несколько читателей. Приходит писатель. Пока ему писать запрещено: он ждёт. В это время приходят ещё читатели. Какого условие, разрешающее ему начать писать?

но ведь возможно что tmp > 0, а key уже -1, тогда после key-- он станет -2 (с печальными последствиями)

Не вижу печальных последствий)) Ну пусть key == -2, ну и что? Следующий виток цикла:
tmp = ++key;
tmp == -1; key == -1;
условие if (tmp) - не выполняется и как следствие нет и key--;
переходим к следующему витку.
Или я всё же не прав?
  

[Igors]

Не возражаю)

Ок  

Мне интересно следующее: Пусть писатель W1 пишет данные, приходят ещё несколько писателей. Пока они ждут своей очереди. Теперь приходит читатель R1, читать пока запрещено, пока W1 пишет. Вопрос, когда будет разрешено читать R1? Когда допишет текущий W1 или пока допишут все писатели, что заявили о себе до прихода R1?

В примерах реализаций этой темы - как получится, заявления писателей хранятся как булевский флажок. Реализация когда отслеживается и число заявок на запись возможна, но особой необходимости в ней нет, т.к. ждущий писатель немедленно выставит запрос опять если он был сброшен.

Аналогичный вопрос, но с ситуацией, когда изначально читали несколько читателей. Приходит писатель. Пока ему писать запрещено: он ждёт. В это время приходят ещё читатели. Какого условие, разрешающее ему начать писать?

Когда закончат чтение все начавшие ДО установки запроса на запись - в этом смысл pending

Не вижу печальных последствий)) Ну пусть key == -2, ну и что? Следующий виток цикла:
tmp = ++key;
tmp == -1; key == -1;
условие if (tmp) - не выполняется и как следствие нет и key--;
переходим к следующему витку.
Или я всё же не прав?

Ну как же не выполняется: if (-1) возвращает true  

[m_ax]

Ну как же не выполняется: if (-1) возвращает true  Улыбающийся

Ой, совсем я уже того))
Разумеется нужно
if (tmp > 0) --key;

[brankovic]

Про Ваш мьютекс. Там опять присвоение, и оно опять компрометирует атомарность:

T1, T2 пришли, захватили ключи 0 и 1, key = 1
T1 отработал и ушёл, key = -1
T2 решил сделать --key, и завис навсегда (между key = -1 и -2)

Нет, не зависнет он навсегда, поскольку key-- будет только тогда, когда tmp > 0

> 0 или != 0 неважно, ещё раз подробнее:

T1, T2 пришли, захватили ключи 0 и 1, key = 1
T2 приготовился сделать --key
T2 заснул
T1 отработал и ушёл, key = -1
T2 проснулся, сделал --key, и завис навсегда между key = -1 и -2

[m_ax]

Про Ваш мьютекс. Там опять присвоение, и оно опять компрометирует атомарность:

T1, T2 пришли, захватили ключи 0 и 1, key = 1
T1 отработал и ушёл, key = -1
T2 решил сделать --key, и завис навсегда (между key = -1 и -2)

Нет, не зависнет он навсегда, поскольку key-- будет только тогда, когда tmp > 0

> 0 или != 0 неважно, ещё раз подробнее:

T1, T2 пришли, захватили ключи 0 и 1, key = 1
T2 приготовился сделать --key
T2 заснул
T1 отработал и ушёл, key = -1
T2 проснулся, сделал --key, и завис навсегда между key = -1 и -2

Прошу прощения, но я Вам не верю)
Вот как я это вижу (поэтапно):

Код

C++ (Qt)
void lock() {
        int key = 0;
        do {
            key = ++m_key;
            if (key > 0) m_key--;
        } while (key != 0);
    }
 
    void unlock() {
        m_key = -1;
    }
 

1) Приходят писатели W1 и W2.
2) W1 делает key = ++m_key; (m_key = 0, key = 0)
3) W2 делает key = ++m_key; (m_key = 1, key = 1)
4) W1 проходит и начинает писать данные, W2 ждёт.
5) Пусть m_key == 1 и W2 приготовился сделать --key и заснул (соответственно key == 1).
6) W1 отработал и сделал m_key = -1;
7) W2 проснулся и сделал --m_key. Проверил не выполняется ли while (key != 0) - выполняется!
Делает следующий виток: key = ++m_key; (key == -1, m_key == -1)
9) W2 проверяет условие if (key > 0) - не выполняется! Не делает key-- !
10) W2 проверяет условие while (key != 0) - выполняется! Делает следующий виток:
11) key = ++m_key; (key == 0, m_key == 0).
12) Проверяет условие if (key > 0) - не выполняется! Не делает --key!!
13) Проверяет условие while (key != 0) - Не выполняется! Начинает писать данные.
Где ошибка??

[brankovic]

Прошу прощения, но я Вам не верю)

да, действительно > 0 прошлый сценарий исключает. Тогда так:

T1 захватил
T2 пришёл и собрался делать --m_key, m_key = 1
T1 отпустил, m_key = -1, ушёл
T3 пришёл, захватил (m_key был -1), m_key = 0
T2 сделал --m_key и на следующем витке захватил

теперь T2 и T3 оба захватили мьютекс

[Igors]

1) Приходят писатели W1 и W2.
2) W1 делает key = ++m_key; (m_key = 0, key = 0)
3) W2 делает key = ++m_key; (m_key = 1, key = 1)
4) W1 проходит и начинает писать данные, W2 ждёт.
5) Пусть m_key == 1 и W2 приготовился сделать --key и заснул (соответственно key == 1).
6) W1 отработал и сделал m_key = -1;
7) W2 проснулся и сделал --m_key. Проверил не выполняется ли while (key != 0) - выполняется!
Делает следующий виток: key = ++m_key; (key == -1, m_key == -1)
9) W2 проверяет условие if (key > 0) - не выполняется! Не делает key-- !
10) W2 проверяет условие while (key != 0) - выполняется! Делает следующий виток:
11) key = ++m_key; (key == 0, m_key == 0).
12) Проверяет условие if (key > 0) - не выполняется! Не делает --key!!
13) Проверяет условие while (key != 0) - Не выполняется! Начинает писать данные.
Где ошибка??

Позвольте спросить: ну а на <..> создавать конструкцию которая может потребовать столь "углубленного анализа"?    Это что, практично? Профессионально? Попробуйте один раз применить CAS - и, уверяю Вас, все проблемы исчезнут 

[m_ax]

да, действительно > 0 прошлый сценарий исключает. Тогда так:

T1 захватил
T2 пришёл и собрался делать --m_key, m_key = 1
T1 отпустил, m_key = -1, ушёл
T3 пришёл, захватил (m_key был -1), m_key = 0
T2 сделал --m_key и на следующем витке захватил

теперь T2 и T3 оба захватили мьютекс

Да, согласен)

Позвольте спросить: ну а на <..> создавать конструкцию которая может потребовать столь "углубленного анализа"?  Улыбающийся  Это что, практично? Профессионально? Попробуйте один раз применить CAS - и, уверяю Вас, все проблемы исчезнут  Улыбающийся

И опять-таки согласен)

Короче, убедили)