Контейнеры STL vs контейнеры Qt

Ссылки были выше.

http://doc.trolltech.com/4.6/threads-reentrancy.html

Throughout the documentation, the terms reentrant and thread-safe are used to mark classes and functions to indicate how they can be used in multithread applications:

* A thread-safe function can be called simultaneously from multiple threads, even when the invocations use shared data, because all references to the shared data are serialized.

* A reentrant function can also be called simultaneously from multiple threads, but only if each invocation uses its own data.

Hence, a thread-safe function is always reentrant, but a reentrant function is not always thread-safe.

By extension, a class is said to be reentrant if its member functions can be called safely from multiple threads, as long as each thread uses a different instance of the class. The class is thread-safe if its member functions can be called safely from multiple threads, even if all the threads use the same instance of the class.

http://doc.trolltech.com/4.5/threads.html

Reentrancy and Thread-Safety

там и про методы и про класыы.

Вот собственно исчерпывающее определение потокобезопасного класса

http://doc.trolltech.com/4.6/threads-reentrancy.html

The class is thread-safe if its member functions can be called safely from multiple threads, even if all the threads use the same instance of the class.

An easy way to make the class thread-safe is to protect all access to the data members with a QMutex

Dendy> Термин thread-safe относится не к классам, а к методам классов.

Qt> a class is said to be reentrant if each and every one of its functions can be called simultaneously by multiple threads on different instances of the class. Similarly, the class is said to be thread-safe [...]

Аккуратнее надо с терминами.

Qt> POSIX uses a somewhat different definition of reentrancy and thread-safety for its C APIs.

Впрочем, это не только к тебе относится.

Отсда вывод, что QString не является потокобезопасным классом, но при этом жрёт ресурсы из-за проверок счётчиков при изменениях его данных, чего нет в std::string, vector, list, map.

> Что лучше использовать? Зачем вообще в Qt плодят сущности?

Контейнеры STL реализованы внешней (по отношению к QT) библиотекой, реализации могут очень сильно различатся, очевидна сложность с расширением возможностей контейнеров; QT контейнеры - везде одинаковые.

Не придирайся к словам, вырванным из контекста:

«Термин thread-safe применяется не к классам, а к методам класса. Если все методы в классе thread-safe - весь класс называется thread-safe для удобства, чтобы не повторяться в каждом методе отдельно. Если не все методы thread-safe - как каждого метода в отдельности делается приписка thread-safe он или нет.»

- в твоей цитате следующее же предложение описывает твои придирки.

> Не придирайся к словам, вырванным из контекста:

Я придираюсь к отсебятине. Конкретно - к словам «не к классам».

Qt> Throughout the Qt documentation, the terms reentrant and thread-safe are used to specify how a function can be used in multithreaded applications

Покажи мне тут слова «не к классам».

Класс - лишь частный случай, когда в функцию подставляется указатель this. В классах может быть зоопарк всевозможных функций. Сегодня он был потокобезопастным, завтра стал нет, потому что в него добавили reentrant-метод. Поэтому называть класс reentrant или thread-safe можно с натяжкой, даже если конкретно сейчас является тем или другим.

Вообще я посмотрел на документацию qt и создалось впечатление, что они неправильно термин reentrant используют:

A reentrant function can also be called simultaneously from multiple threads, but only if each invocation uses its own data.

и

By extension, a class is said to be reentrant if its member functions can be called safely from multiple threads, as long as each thread uses a different instance of the class.

Вам, не кажется, что это не тоже самое, что и «повторная входимость»?

И тем более «Hence, a thread-safe function is always reentrant, but a reentrant function is not always thread-safe.»

В той же википедии есть правильное определение:

Both concepts of reentrancy and thread safety relate to the way functions handle resources. However, they are not the same. While the concept of reentrancy can affect the external interface of a function, thread safety only concerns the implementation of the function and not its external interface.

In most cases, to make a non-reentrant function reentrant, its external interface must be modified such that all data is provided by the caller of the function.

To make a thread-unsafe function thread-safe, only the implementation needs to be changed, usually by adding synchronization blocks to protect shared resources from concurrent accesses by different threads.

Therefore, reentrancy is a more fundamental property than thread-safety and by definition, leads to thread-safety: Every reentrant function is thread-safe; however, not every thread-safe function is reentrant.

Или это как раз «не соответствие POSIX» про которое выше говорилось?

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

Только это не программа, а хрен его знает что такое будет. Поэтому к классу ещё как применимо понятие «потокобезопасный». Он так спроектирован для решения потокобезопасных задач.

В Википедии видимо раскрывается более фундаментальное понятие. Думать о reentrancy как о механизме защиты данных, которые подставляешь в функцию. А thread-safety они рассматривают как функцию с опциональными данными, то-есть их может и не быть, главное - что тело функции может вызываться из разных потоков.

В Qt эти же термины используются применительно к классам. То-есть они рассматривают не статические функцию, а методы классов, что навязывает условие, что как минимум в thread-safe функцию передаётся указатель на this, и его тоже нужно защитись.

Выходит что reentrant функция без данных - всегда thread-safe. При этом thread-safe метод - всегда reentrant. Собственно, противоречий не вижу.

И тоже самое можно сказать про функции.

Функция - готовый интерфейс, если у неё завтра будет другое поведение, значит интерфейс сломан. Добавление же нового метода в класс старый интерфейс не ломает. Зато возможно ломает псевдо-понятие thread-safe/reentrant.

Пример. У нас есть класс, которые неоптимально, зато безопастно добавляет в себя данные:

void MyClass::addSafe(int); // thread-safe

В следующей версии могут добавиться методы, позволяющие осуществлять синхронизацию самому:

void MyClass::lock();         // thread-safe
void MyClass::unlock();       // thread-safe
void MyClass::addUnsafe(int); // thread-unsafe

> Говоря о доступе уточнили бы, что имеются в виду мутабельные операции, а то ведь совершенно непонятно.

Чего ж тут не понятного? Если не оговорено иное, доступ - rw. Ибо не rw уже не совсем «доступ».

Потокобезопасность не псевдо-понятие, а требование. Класс CThreadSafeString обязан работать в многопоточной среде без дополнительных усилий. Если это нарушается, то значит допущена ошибка в реализации и её надо исправить.

И вообще это разговор ни о чём. У меня пара функций в некоем классе, которые работают из потоков, завёрнуты в мьютексы. Остальные не завёрнуты, потому что им не надо. Вот и всё. И мне как-то наплевать, как будет называться это класс: потокобезопасный или опасный. Главное оно работает.

> Пизди^WВрешь, не было у нас этого в 1-м семестре.

Точно вру. «Структуры данных», где рассказывали про списки-стеки-вектора был таки на 3-ем семестре.