powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / взаимодействие между потоками, сигнал из одного потока в другой
25 сообщений из 73, страница 2 из 3
взаимодействие между потоками, сигнал из одного потока в другой
    #38328248
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zMasterZivпропущено...
Между потоками лучше -- критическая секция. В windows.
Критическая секция - вариант мьютекса, где по сути невозможно выполнение какого то кода одновременно несколькими потоками, напр. доступа к данным.
В чем будет преимущество по сравнению с "классическим" вариантом мьютекса для данной задачи?
Критические секции и мьютексы в винде (первые только в винде и есть) объекты с совершенно различными характеристиками, первые - объекты пользовательского режима, вторые объекты ядра. Если вы бездумно будете взаимозаменять их получите либо постоянно загруженный проц, либо низкую производительность.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328331
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sherzod_,

А почему вы решили, что то что характеристики производительности зависят от того пользовательский это объект или ядерный?
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328338
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,
что есть "переменная" ? Слот в TLS - переменная или нет?
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328350
m_Sla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovskysherzod_,
А почему вы решили, что то что характеристики производительности зависят от того пользовательский это объект или ядерный?Джеффри РИХТЕР
"WINDOWS Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows"

Небольшой тест 12294042
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328390
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
m_Sla,

Я вообще-то про другое спрашивал.
Не про то, какая производительность, а про то как она зависит от того где находится объект синхронизации.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328432
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

От того, где находится объекты синхронизации зависит лишь будет переключаться контекст или нет при захвате критической секции или мьютекса. В случае использования объектов ядра (мьютекса) это приведет к переключению контекста, в случае с критическими секциями - нет. Поэтому, кто программирует на винде и не обременен между процессовой синхронизацией посредством именованных или неименованных мьютексов, используются критический секции для взаимоисключающей блокировки.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328461
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий Широков,

Переключение контекста - это мимо, оно не объясняет почему секция быстрее - секция точно также умеет усыплять ждущий поток - и в этом случае будет переключение контекста, ничем не отличающееся от межпроцессного мьютекса.
Быстрее она не потому что создается в юзерспейсе, а потому что имеет ряд оптимизаций, которые точно также могли бы внести в мьютекс, но не стали.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328482
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyАнатолий Широков,

Переключение контекста - это мимо, оно не объясняет почему секция быстрее - секция точно также умеет усыплять ждущий поток - и в этом случае будет переключение контекста, ничем не отличающееся от межпроцессного мьютекса.
Быстрее она не потому что создается в юзерспейсе, а потому что имеет ряд оптимизаций, которые точно также могли бы внести в мьютекс, но не стали.

В случае невозможности заблокировать ресурс посредством критической секции безусловно ты получишь переключение контекста, а вот в случае успеха - нет. Так что не руби с плеча, утверждая, что переключение контекста здесь "мимо".
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328507
m_Sla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyАнатолий Широков,
Переключение контекста - это мимо, оно не объясняет почему секция быстрее - секция точно также умеет усыплять ждущий поток - и в этом случае будет переключение контекста, ничем не отличающееся от межпроцессного мьютекса.
Быстрее она не потому что создается в юзерспейсе, а потому что имеет ряд оптимизаций, которые точно также могли бы внести в мьютекс, но не стали.из Рихтера:
"В этой главе мы рассмотрим, как синхронизировать потоки с помощью объектов ядра. Вы увидите, что такие объекты предоставляют куда больше возможностей, чем механизмы синхронизации в пользовательском режиме. В сущности, единственный их недостаток — меньшее быстродействие Дело в том, что при вызове любой из фун кций, упоминаемых в этой главе, поток должен перейти из пользовательского режи ма в режим ядра. А такой переход обходится очень дорого — в 1000 процессорных тактов на платформе x86 Прибавьте сюда еще и время, которое необходимо на вы полнение кода этих функций в режиме ядра."

Так понимаю процессор с ring3 переключается на ring0, а потом назад. На этом время и теряется.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328544
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
m_Sla,

Я тут подумал, что переключение в ядро нужно не для реализации функционала мьютекса, а для защиты памяти ядра в которой находится мтьютекс от некорректных программ.
А посколько такая защита по-любому нужна в многозадачных системах, то получается я был не прав и объекты синхронизации в ядре всегда будут иметь этот оверхед по сравнению с юзерскими.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328743
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На самом деле почему мьютекс сложно оптимизировать — по-моему так вполне очевидно, мьютекс для приложения — это только хэндл, псевдоуказатель, а данных у приложения нет вообще, и чтобы что-то с ним сделать, нужно уйти в код операционки, где какие-то данные мьютекса есть. А критическая секция наоборот уже в себе содержит данные, это обычная с-структура. Приложение само может с ней что-то сделать.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38328744
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий ШироковAnatoly Moskovsky,
... Поэтому, кто программирует на винде и не обременен между процессовой синхронизацией посредством именованных или неименованных мьютексов, используются критический секции для взаимоисключающей блокировки. Другие этим тоже не обременены, критические секции это всего-лишь виндовая оболочка над возможностями interlocked функций, которые по сути аппаратные. В линуксе например аналог - futex (fast userspace mutex).
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329293
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivНа самом деле почему мьютекс сложно оптимизировать — по-моему так вполне очевидно, мьютекс для приложения — это только хэндл, псевдоуказатель, а данных у приложения нет вообще, и чтобы что-то с ним сделать, нужно уйти в код операционки, где какие-то данные мьютекса есть. А критическая секция наоборот уже в себе содержит данные, это обычная с-структура. Приложение само может с ней что-то сделать.
Оптимизировать как раз можно - разместить мьютекс в разделяемую память и исчезнет необходимость на каждый чих в ядро переключаться. В винде есть куча хендлов, которые по сути являются адресами в юзерском процессе. Т.е. такая практика существует.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329326
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyMasterZivНа самом деле почему мьютекс сложно оптимизировать — по-моему так вполне очевидно, мьютекс для приложения — это только хэндл, псевдоуказатель, а данных у приложения нет вообще, и чтобы что-то с ним сделать, нужно уйти в код операционки, где какие-то данные мьютекса есть. А критическая секция наоборот уже в себе содержит данные, это обычная с-структура. Приложение само может с ней что-то сделать.
Оптимизировать как раз можно - разместить мьютекс в разделяемую память и исчезнет необходимость на каждый чих в ядро переключаться. В винде есть куча хендлов, которые по сути являются адресами в юзерском процессе. Т.е. такая практика существует.

Слой хендлов обеспечивает безопасность ядра от несанкционированного доступа к реальным данным. То о чем говоришь ты существовало ранее и от чего современные версии Windows ушли.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329347
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий Широков,

Да никто никуда от этого не ушел.
Например http://stackoverflow.com/questions/6734095/how-to-get-module-handle-from-func-ptr-in-win32
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329359
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий ШироковAnatoly Moskovskyпропущено...
Оптимизировать как раз можно - разместить мьютекс в разделяемую память и исчезнет необходимость на каждый чих в ядро переключаться. В винде есть куча хендлов, которые по сути являются адресами в юзерском процессе. Т.е. такая практика существует.
Слой хендлов обеспечивает безопасность ядра от несанкционированного доступа к реальным данным. То о чем говоришь ты существовало ранее и от чего современные версии Windows ушли. Да и вряд ли переключение в контекст ядра связано исключительно с безопасностью. Если при спин-блокировке потоки еще смогут разрулиться без участия ядра (в частности планировщика), то при мьютексе этого никак не достичь кодом юзерспейса - нужно участие планировщика, нужно участие алгоритма очереди ожидания (хотя при мьютексе он вырождается конечно, но все же), чтобы уравнивать шансы на захват блокировки, да и много чего еще там ведь происходит.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329405
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sherzod_,

Я отвечал на конкретный пост относительно предложения приоткрыть завесу "потрохов" объектов ядра для клиентского кода и невозможность это сделать в контексте обеспечения безопасности ядра, кроме как через легальный API. Ясно, что в случае мьютексов надо было бы перенести на пользовательский уровень и много чего другого для обеспечения имитации функционала API .
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329409
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly Moskovsky,

И что этот пост должен продемонстрировать, что имея легальный API можно получить соответствие между объектом и его HANDLE-ом? А что с этим кто-то спорил?
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329423
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий ШироковAnatoly Moskovsky,

И что этот пост должен продемонстрировать, что имея легальный API можно получить соответствие между объектом и его HANDLE-ом? А что с этим кто-то спорил?
Код: plaintext
1.
(HMODULE)mbi.AllocationBase


AllocationBase это адрес в процессе, а HMODULE это хендл.
Между ними не просто есть соответствие. Это одно и тоже.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329429
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кроме того, в том посе опровергается утверждение "существовало ранее и от чего современные версии Windows ушли" и показано на примере HMODULE что был как раз обратный процесс - изначально HMODULE был просто числом, а в современных версиях стал адресом.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329441
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий ШироковЯ отвечал на конкретный пост относительно предложения приоткрыть завесу "потрохов" объектов ядра для клиентского кода и невозможность это сделать в контексте обеспечения безопасности ядра, кроме как через легальный API. Ясно, что в случае мьютексов надо было бы перенести на пользовательский уровень и много чего другого для обеспечения имитации функционала API .
Кроме безопасности нет никаких преград для реализации мьютекса в юзерспейсе.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329479
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyАнатолий ШироковЯ отвечал на конкретный пост относительно предложения приоткрыть завесу "потрохов" объектов ядра для клиентского кода и невозможность это сделать в контексте обеспечения безопасности ядра, кроме как через легальный API. Ясно, что в случае мьютексов надо было бы перенести на пользовательский уровень и много чего другого для обеспечения имитации функционала API .
Кроме безопасности нет никаких преград для реализации мьютекса в юзерспейсе.

Даже в случае междупроцессного взаимодействия?
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329488
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyКроме того, в том посе опровергается утверждение "существовало ранее и от чего современные версии Windows ушли" и показано на примере HMODULE что был как раз обратный процесс - изначально HMODULE был просто числом, а в современных версиях стал адресом.

Соглашусь, что в данном конкретном случае, это так. Но это, скорее, исключение, чем правило.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329510
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Анатолий ШироковAnatoly MoskovskyКроме безопасности нет никаких преград для реализации мьютекса в юзерспейсе.
Даже в случае междупроцессного взаимодействия?
Да.
Например выше приводили futex. На основе этого примитива можно реализовать быстрый мьютекс в юзерспейсе (в разделяемой памяти для межпроцессного мьютекса).
Уверен что под виндой вполне можно было реализовать аналогичный АПИ.
...
Рейтинг: 0 / 0
взаимодействие между потоками, сигнал из одного потока в другой
    #38329525
Фотография Анатолий Широков
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Anatoly MoskovskyАнатолий Широковпропущено...

Даже в случае междупроцессного взаимодействия?
Да.
Например выше приводили futex. На основе этого примитива можно реализовать быстрый мьютекс в юзерспейсе (в разделяемой памяти для межпроцессного мьютекса).
Уверен что под виндой вполне можно было реализовать аналогичный АПИ.

Доступ к разделяемой памяти надо синхронизировать, а для этого надо нечто уровня ядра. А раз уровня ядра, вынь да полож накладные расходы на переключение.
...
Рейтинг: 0 / 0
25 сообщений из 73, страница 2 из 3
Форумы / C++ [игнор отключен] [закрыт для гостей] / взаимодействие между потоками, сигнал из одного потока в другой
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]