Добрый день. Помогите пожалуйста разобраться со следующей проблемой: В контексте некоторого процесса имеется некоторый код (не поток!). Как и когда он туда попал - неважно. Смысл в том, что иногда он вызывается каким-либо (с равной вероятностью - любым) функционирующем в этом процессе потоком. В этом коде имеется определенная функция, выполнять которую необходимо при гарантии, что остальные потоки во время ее выполнения не будут шевелиться. Т.е. необходимо саспендить все незасаспенденные остальные потоки перед вызовом этой функции, и отпускать их после. Проблема в том, что по определенным причинам нежелательно получать список потоков и саспендить каждый в отдельности. Интересует вопрос, существуют ли какие-либо иные методы, позволяющие гарантированно вытеснить на время выполнения этой функции остальные потоки, чтобы планировщик не дал им работать? Желательно, чтобы это еще и побыстрее работало=) Вообще, какие существуют методы заморозки всех потоков кроме текущего в своем процессе? ЗЫ В ядро лазать нельзя!
Вашего процесса? Судя по фразе вы творите нечто несовсем легальное Если так, то по-моему придется тормозить потоки по одиночке. Если же вы сами конструируете все вызывающие ваш код потоки, то воспользуйтесь mutex'ом
Или критической секцией, а не mutex'ом. По информации Platform SDK критическая секция быстрее mutex'а, а других различий между ними для потоков одного процесса нет.
Если приоритет одного из потоков я повышаю до реалтаймовского, разве остальные потоки этого процесса во время работы моего потока в реалтайме никогда не получат управления? Легальное=) Определенные причины заключаются в том, что мой код будет вызываться достаточно часто и, соответственно, функция, запрещающая работу другим потокам должна работать как можно быстрее. Поэтому получать список потоков и тормозить их по одному, а затем снова получать и проверять, не успели ли еще создаться и тормозить новые и т.д. в цикле неособо хорошо... Критические секции не годятся... Мне же нужно, чтобы все потоки функционировали нормально до вызова моего кода. Потоки создаю не я. Можно считать, я просто записываю в память левого процесса свой код и патчу оригинальный, чтобы мой иногда вызывался.
MoonShiner Если точка входа в твой код, для всех сторонних потоков одинакова - можешь второй командой его сделать патч первой (SMC). Это может дать потерю до 4000 тиков, но зато реализуется достаточно просто, если в секцию твоего кода уже разрешена запись: <font face="fixedsys] <font size=1> start_code: jmp $+2 mov byte ptr [start_code + 1], end_code - start_code ... ; some code (small or call big proc) mov byte ptr [start_code + 1], 0 ;; unpatch end_code: </font><!--size--> </font><!--face--> Но в принципе, в этом случае ГОС и крит.секции гораздо надежнее, на худой конец можно воспользоваться одной из Interlocked функций.
MoonShiner Пока твой поток сам не отдаст управление или пока не появиться поток с неменьшим приоритетом твой поток не будет прерван. А зачем собственно останавливать остальные потоки? Если нужно остановить потоки при входе в свой код, то нет ничего быстрее критических секций со спин блокировками. Если нужно просто сделать апи хуки, то для этого не обязательно останавливать сторонние потоки, создание true функции с помощью копирования оригинальных байт функции в буффер и установки jmp а продолжение рулит.
