Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
14.11.2015, 12:31
|
|||
|---|---|---|---|
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
Иными словами, что блокируют мьютексы и критические секции: участки кода или объекты, находящиеся под их воздействием? Верно ли, что заблокированный мьютексом член класса можно изменить другим потоком в другой функции этого же класса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 13:06
|
|||
|---|---|---|---|
|
|||
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
мутекс блокирует только мутекс... больше ничего. то есть.. Код: plaintext 1. 2. 3. 4. 5. 6. теперь эту функцию можно исполнять из любого потока. но, если другой поток испольнит такую функцию Код: plaintext 1. 2. 3. 4. то он нарушит работу.. то есть вывестесь на экран может тогда hegoodllobay ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 14:19
|
|||
|---|---|---|---|
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
А если дописать Код: plaintext 1. 2. 3. 4. 5. , то уже нельзя будет одновременно заходить в Код: plaintext 1. и Код: plaintext 1. , в предположении, что мьютекс является членом foo? Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 14:22
|
|||
|---|---|---|---|
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
Мутекс, хоть блокированный хоть что, сам по себе не защищает ничего. Это просто некое состояние, используя которое можно синхронизировать потоки с помощью прилагаемых методов и только их . А можно сделать memset(&mutex, 0, sizeof(mutex)) и никто и слова поперек не скажет (и не сможет предсказать в общем случае что из этого выйдет). P.S. операции ввода-вывода атомарны друг относительно друга. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 14:36
|
|||
|---|---|---|---|
|
|||
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
log_here, да. то есть нужно определить какие имеено переменные защищает мутест. перед обращением к этим переменным, от куда угодно, обязательно нужно взять мутекс. если не возьмешь, защиты нет. то есть если один метод берет, а другой нет, то тот метод, который берет, можно вызывать из разных потоков, а тот который не берет, нельзя. wst, ну да ,наверное с выводом я перепутал. но запись в поток не атомарна. то есть в запись Код: plaintext 1. может вклиниться любой другой код и получится hello other code world или что-нибудь в этом духе. то есть можно вклиниться между операторами << ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 15:59
|
|||
|---|---|---|---|
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
log_hereА если дописать Код: plaintext 1. 2. 3. 4. 5. , то уже нельзя будет одновременно заходить в Код: plaintext 1. и Код: plaintext 1. , в предположении, что мьютекс является членом foo? Код: plaintext 1. 2. 3. 4. 5. Заходить можно, но только до точки std::lock_guard<std::mutex> lock(mutex_); Т.е. метод some или other получает управление, выполняет код который предшествует созданию объекта lock, и блокируется на вызове lock, если mutex_ уже занят. Нет никакой необходимости размещать создание блокировки в самом начале метода. И нет нужды удерживать блокировку до самого конца. В методе можно сгруппировать код, который пишет/читает разделяемую память и защитить только этот блок кода. .... { std::lock_guard<std::mutex> lock(mutex_); l = share_; share_ = l + 1; } ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2015, 16:27
|
|||
|---|---|---|---|
|
|||
Может ли другой поток изменить заблокированный мьютексом объект? |
|||
|
#18+
ну.. как бы мутокс блокируется вызовом метода mutex_.lock() и разблокируется вызовмо методв mutex_.unlock(); если один поток вызвал метод mutex_.lock(), то другой поток, который тоже вызовет lock на этом же метексе встанет и будет ждать, пока первый поток не вызовет mutex_.unlock(). на этом вся синхронизация. std::lock_guard - это просто класс ,который в конструкторе вызовет lock для переданного мутекса, а в деструкторе unlock . поэтому когда из облатси видимости выйдет объект этого класса, мутекс разблокируется. если его не использовать, то можно получить вечную блокировку. Код: plaintext 1. 2. 3. если вызов do_some определен так Код: plaintext 1. то до строки mutex_.unlock() поток не дойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=57&mobile=1&tid=2018742]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
80ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 301ms |
| total: | 469ms |

| 0 / 0 |
