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

[brankovic]

А за счёт чего достигается атомарность копирования shared_ptr? Вот например:

Код

C++ (Qt)
shared_ptr<Data> ptr;
DataManager dataManager;
...
ptr = dataManager.data();
 

При копировании, на сколько я понял должно произойти как минимум следующее:
ptr - должен уменьшить свой счётчик ссылок и если он окажется 0 удалить сам объект,
скопировать указатель на новые данные и опять увеличить счётчик ссылок.
Наверное я чегото не допонимаю в этом, почему оно атомарно? 

Только за счёт мьютекса, в данном примере. Дальше боюсь запутать, пытаясь домыслить неправильно поставленный вопрос.

[Igors]

Только за счёт мьютекса, в данном примере. Дальше боюсь запутать, пытаясь домыслить неправильно поставленный вопрос.

Попробую я пояснить

Код

C++ (Qt)
shared_ptr<Data> ptr;
DataManager dataManager;
...
for (int i = 0; i < 100 ++i) {
 ptr = dataManager.data();
 ...
}
 

Вполне возможно что напр после первых 10 итераций цикла др. нитка поставит др. data. В этом случае следующие итерации цикла будут работать уже с новыми данными. Это "атомарно" и будет работать корректно. Однако это совсем не значит что данные будут изменены для того кто их уже получил (до замены) с помощью data() - что получил, с тем и работает

[m_ax]

Только за счёт мьютекса, в данном примере. Дальше боюсь запутать, пытаясь домыслить неправильно поставленный вопрос.

Попробую я пояснить

Код

C++ (Qt)
shared_ptr<Data> ptr;
DataManager dataManager;
...
for (int i = 0; i < 100 ++i) {
 ptr = dataManager.data();
 ...
}
 

Вполне возможно что напр после первых 10 итераций цикла др. нитка поставит др. data. В этом случае следующие итерации цикла будут работать уже с новыми данными. Это "атомарно" и будет работать корректно. Однако это совсем не значит что данные будут изменены для того кто их уже получил (до замены) с помощью data() - что получил, с тем и работает

Да, это я понял) Всмысле, это вполне нормальное поведение (кто успел - тот съел )

А за счёт чего достигается атомарность копирования shared_ptr? Вот например:

Код

C++ (Qt)
shared_ptr<Data> ptr;
DataManager dataManager;
...
ptr = dataManager.data();
 

При копировании, на сколько я понял должно произойти как минимум следующее:
ptr - должен уменьшить свой счётчик ссылок и если он окажется 0 удалить сам объект,
скопировать указатель на новые данные и опять увеличить счётчик ссылок.
Наверное я чегото не допонимаю в этом, почему оно атомарно? 

Только за счёт мьютекса, в данном примере. Дальше боюсь запутать, пытаясь домыслить неправильно поставленный вопрос.

Хорошо, тогда получается, что сама по себе операция копиррования и присваивания двух shared_ptr (я иммею в виду без участия DataManager) не является атомарной?
А, если является, то это обеспечивается собственным мьютексом в самом shared_ptr? Тогда, если это так, то какой смысл в Read(Write)Locker в классе DataManager?

И ещё вопрос: В классе DataManager используется shared_ptr только лишь как оптимизация? Ведь аналогичный эффект получится если просто использовать непосредственно Data? 

[brankovic]

Хорошо, тогда получается, что сама по себе операция копиррования и присваивания двух shared_ptr (я иммею в виду без участия DataManager) не является атомарной?

да (не является атомарной для любого разумного определения атомарности)

Edit: собственно термин "атомарный" допускает трактовки. Атомарная функция или operator= -- это непонятно что, надо ещё определение дать функциональной атомарности.

И ещё вопрос: В классе DataManager используется shared_ptr только лишь как оптимизация? Ведь аналогичный эффект получится если просто использовать непосредственно Data? 

да

Как пример, такие DataManager-ы используется для классов хранения сеттингов (настройки программы), они могут быть довольно развесистыми. Рабочий тред пользуется сеттингами, но он 1) не должен их на долго лочить, 2) должен видеть консистентное состояние настроек. Такая конструкция с shared_ptr позволяет ускорить захват сеттингов. Но необходимости в shared_ptr здесь нет, просто он копируется на порядок быстрее, чем какой-нибудь std::map <std::string, std::vector <boost::any> >.

[m_ax]

Хорошо, тогда получается, что сама по себе операция копиррования и присваивания двух shared_ptr (я иммею в виду без участия DataManager) не является атомарной?

да

И ещё вопрос: В классе DataManager используется shared_ptr только лишь как оптимизация? Ведь аналогичный эффект получится если просто использовать непосредственно Data? 

да

Как пример, такие DataManager-ы используется для классов хранения сеттингов (настройки программы), они могут быть довольно развесистыми. Рабочий тред пользуется сеттингами, но он 1. не должен их лочить, 2. должен видеть консистентное состояние настроек. Такая конструкция с shared_ptr позволяет ускорить захват сеттингов и тем самым минимизировать трение в локах. Но необходимости в shared_ptr здесь нет, просто он копируется на порядок быстрее, чем какой-нибудь std::map <std::string, std::vector <boost::any> >.

Ясно  Спасибо)

[vregess]

В дополнение ко всему сказанному

Не понял Вашей задумки: m_data "улетела" (из метода data) и тот кто ее подхватит будет использовать указатель на ее данные. Этот "улетевший" указатель не будет обновлен после setData, в чем тогда смысл?

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

Код:

class Data {}

class DataManager
{
public:
    ...

    // Раньше было data()
    SharedPointer<Data> getDataSnapshot() const
    {
         ReadLocker lock;
         return m_data;
    }
    ...
}

Здесь мне видится один недостаток: после получения SharedPointer<Data> у нас будет возможность менять данные по указателю. Но с практической точки зрения работать будет быстрее, чем делать класс Data синхронизированным. Да и обойти это можно в принципе.

[Igors]

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

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

Здесь мне видится один недостаток: после получения SharedPointer<Data> у нас будет возможность менять данные по указателю. Но с практической точки зрения работать будет быстрее, чем делать класс Data синхронизированным. Да и обойти это можно в принципе.

Частенько "в принципе" просто означает "никогда"  

[vregess]

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

Да, может и так. Видимо по этому чаще встречается описание примеров именно с  обычной синхронизацией запись/чтение.

Частенько "в принципе" просто означает "никогда" 

Ну я имел ввиду, что это возможно. Простой пример:

void SomeClass::foo()
{
    SharedPointer<Data> data = cfg.getDataSnapshot();
    Data *ptr = data.get();
    assert(prt);
    doStuff(*ptr);
}

void SomeClass:doStuff(const Data &data)
{
   ...
}

Писанины больше, но и скорость выполнения тоже. Иногда это оправдано, иногда - нет.

[Akon]

В дополнение ко всему сказанному

Не понял Вашей задумки: m_data "улетела" (из метода data) и тот кто ее подхватит будет использовать указатель на ее данные. Этот "улетевший" указатель не будет обновлен после setData, в чем тогда смысл?

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

Код:

class Data {}

class DataManager
{
public:
    ...

    // Раньше было data()
    SharedPointer<Data> getDataSnapshot() const
    {
         ReadLocker lock;
         return m_data;
    }
    ...
}

Здесь мне видится один недостаток: после получения SharedPointer<Data> у нас будет возможность менять данные по указателю. Но с практической точки зрения работать будет быстрее, чем делать класс Data синхронизированным. Да и обойти это можно в принципе.

Для большей строгости можно использовать const propagation:

Код:

...   
     const SharedPointer<Data> getDataSnapshot()
    {
         ReadLocker lock;
         return m_data;
    }

    const SharedPointer<const Data> getDataSnapshot() const
    {
         return const_cast<DataManager*>(this)->getDataSnapshort();
    }
...

Соответственно, у кого const ссылка на DataManager не может изменить состояние данных.

[brankovic]

Для большей строгости можно использовать const propagation:
...
Соответственно, у кого const ссылка на DataManager не может изменить состояние данных.

а почему не сделать так:

Код

C++ (Qt)
    const SharedPointer<const Data> getDataSnapshot () const
    {
         ReadLocker lock;
         return m_data;
    }
 

в чём смысл второго метода с не-конст указателем, если полученный объект нельзя менять всё равно?

[vregess]

Для большей строгости можно использовать const propagation:

Да, я перемудрил. Так лучше.
А еще можно мьютекс сделать mutable и оставить только константный getDataSnapshot()

Код:

...   
     SharedPointer<const Data> getDataSnapshot() const
    {
         ReadLocker lock(m_mutex);
         return m_data;
    }

private:
    mutable Mutex m_mutex;

brankovic уже подметил

[Akon]

Для большей строгости можно использовать const propagation:
...
Соответственно, у кого const ссылка на DataManager не может изменить состояние данных.

а почему не сделать так:

Код

C++ (Qt)
    const SharedPointer<const Data> getDataSnapshot () const
    {
         ReadLocker lock;
         return m_data;
    }
 

в чём смысл второго метода с не-конст указателем, если полученный объект нельзя менять всё равно?

почему полученный объект (Data) нельзя менять?

[Igors]

Если привлекается LockRead, то вся конструкция теряет смысл (какой же это lock-free?). Практичнее прикинуть какой read/write локер пользовать.

[vregess]

почему полученный объект (Data) нельзя менять?

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

И, кстати, const SharedPointer тут не важен, главное чтоб const Data был.

Если привлекается LockRead, то вся конструкция теряет смысл (какой же это lock-free?). Практичнее прикинуть какой read/write локер пользовать.

Да мы вроде уже не о lock-free.

[Akon]

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

согласен

И, кстати, const SharedPointer тут не важен, главное чтоб const Data был.

Это нужно для явной семантики присваивания. Например, без const можно было бы написать getDataSnapshot().reset(newData) или getDataSnapshot() = somePointer, что совершенно бесполезно, поскольку объект временный. Короче, нет никакого смысла менять временный объект, и для предотвращения подобных действий объект возвращается как константный.