Многопоточная запись/чтение implicitly-shared классов

[Akon]

Часто приходится видеть такое:

Код:

QByteArray a("some data");

// write access, thread #1
void funcFromThread1()
{
	a = QByteArray();  // before assignment assume ref. count == 1
	...
}

// read-only access, thread #2
void funcFromThread2()
{
	const QByteArray b = a;  // potential access to released memory (pointed by a.d)
	...
}

В документации сказано о безопасности счетчика ссылок и о небезопасности расшаренных данных. Вероятно, у многих (в т.ч. и у меня) создается впечатление, что shallow copy

Код:

const QByteArray b = a;

безопасно в многопоточной среде, но при одновременном чтении/записи, как приведено выше, это не так.

Безопасный доступ: сериализация (мьютексы) и lock-free вариант, приведенный ниже:

Код:

// lock-free

QByteArray a("some data");

// write access, thread #1
void funcFromThread1()
{
	const QByteArray tmp = a;  // ref.count >= 2 while writing a
	a = QByteArray();
	...
}

// read-only access, thread #2
void funcFromThread2()
{
	const QByteArray b = a;  // safe access while writing a
	...
}

имхо, как-то стоило бы отразить эту проблему в документации, например, в boost подобное использование разжевано для boost::shared_ptr.

[Igors]

Ну Вы бы уж "разжевали" для широкого круга читателей напр

Код

C++ (Qt)
QByteArray &QByteArray::operator=(const QByteArray & other)
{
    other.d->ref.ref();
    if (!d->ref.deref())
        qFree(d);
    d = other.d;
    return *this;
}
 

Читающая нитка может вклиниться перед qFree и рухнуть. Чтобы исключить такое дело надо запастись счетчиком ссылок >= 2. Добавим что читающий может получить как новые так и старые данные - как получится

[Akon]

Да, спасибо за дополнение-"разжевку".

[Авварон]

Igors
присваивание шаред данных атомарно. никто никуда вклинится не может.

[Igors]

присваивание шаред данных атомарно. никто никуда вклинится не может.

Уголовники показывают костяшку домино 5/6 и говорят "выбирай". Что выберет умный человек?  Вот также и читающая нитка 

[andrew.k]

Поясни про уголовников?)

[Igors]

Код

C++ (Qt)
    if (!d->ref.deref())
                                   <-- пробой здесь
        qFree(d);
 

[Авварон]

2 нитки _не могут_ владеть 1й копией. у каждой нитки свой d.

[Akon]

Это так, до поры

Код:

d = other.d;

Про уголовников тоже интересно.

[andrew.k]

2 нитки _не могут_ владеть 1й копией. у каждой нитки свой d.

А почему? В том смысле, где это написано?

Qt uses an optimization called implicit sharing for many of its value class, notably QImage and QString. Beginning with Qt 4, implicit shared classes can safely be copied across threads, like any other value classes. They are fully reentrant. The implicit sharing is really implicit.
Threads and Implicitly Shared Classes
Какой из этого вывод?

[Авварон]

andrew.k
не, это я туплю просто.

[Akon]

Ну там дальше написано

...  Atomic reference counting does, however, guarantee that a thread working on its own, local instance of an implicitly shared class is safe. ...

Но проблема возникает как раз при переустановке своего d.

Авварон
у вас создалось впечатление 

[andrew.k]

Тогда, что получается по теме? я не очень понимаю.
Нужно использовать мютексы при доступе к QByteArray? Потому что без них ерунда какая-то получается.
Мыль ТС я не очень понял. Точнее приведенный там код.

[andrew.k]

Ну там дальше написано

...  Atomic reference counting does, however, guarantee that a thread working on its own, local instance of an implicitly shared class is safe. ...

Но проблема возникает как раз при переустановке своего d.

Получается другой поток в принципе не увидит изменений сделанных другим потоком.

[Igors]

Код

C++ (Qt)
QByteArray &QByteArray::operator=(const QByteArray & other)
{
    other.d->ref.ref();
    if (!d->ref.deref())
        qFree(d);
    d = other.d;
    return *this;
}
 

Допустим d->ref.defref() вернул false и в этот момент ОС передал управление др. нитке. Конечно d = other.d выполнится атомарно, но это будет потом, когда текущая нитка снова получит управление. А сейчас в читающей нитке это d пройдет как член other, ну читатель увеличит счетчик ref и присвоит указатель d своему. Может даже успеет что-то сделать пока проснувшаяся нитка не выполнит qFree