В статье http://wasm.ru/article.php?article=scheduler есть такая фраза: первое и последнее предложения какие-то невнятные, возникает ощущение что речь идет про выполнение одного и того же потока, но ведь это не так?
А что тут непонятного? Поток завершился на обработке прерывания - для продолжения он должен выйти из обработчика.
т.е и в первом прдложении цитаты и во втором речь идет об одном и том же потоке? а где же происходит переключение на другие потоки?
Еще непонятна такая фраза в статье: Что имеется ввиду под словом "перезагрузка"? Просто сохранение KTRAP_FRAME? Вобщем мне непонятно, по мне так на выходе из обработчика должен исполняться уже другой поток (и если б не первая цитата в этой теме я бы так и думал),объясните тогда плз если это не так, когда же успевает выполниться другой поток?
Попробую объяснить на своем коде. Так выглядит конец обработчика: Код (Text): ... mov ebx, [current] dec [ebx+TS.ActivePriority] jnz @f mov eax, [ebx+TS.Priority] mov [ebx+TS.ActivePriority], eax cmp ebx, [ebx+TS.Next] je @f ; я тут сохраняю es, т.к. основной код обработчика не использует es, ; однако внутренние функции ядра, к которым относится и SwitchToNext, ; предполагают при вызове наличие селектора KDATA в ds, es и ss push es push ds ; KDATA pop es call SwitchToNext pop es @@: pop ds pop ebx pop eax iret Внутри SwitchToNext происходит переключение, т.е. конец обработчика будет завершен только после реактивации потока. Это сохранение регистров одного потока и восстановление регистров другого. В виндах вероятно большая часть регистров общего назначения сохраняется и восстанавливается в коде обработчика с помощью pusha/popa и т.п. Я же это делаю в Switch-фрейме, однако и на моем примере можно понять, как это происходит. Можно посмотреть на сохраняемые мной регистры eax, ebx, ds и es. Внутри SwitchToNext они не сохраняются. Однако их значения не теряются в процессе переключения контекстов, т.к. их обязан сохранять код, вызывающий SwitchToNext. Т.е. регистры сохраняются в стеке одного потока, потом происходит переключение (одна из наиболее значимых операций здесь - перезагрузка esp) и аналогичные регистры восстанавливаются, но уже из стека другого потока.
Phantom_84, спасибо за ответ. так значит я верно понял что после возврата из switchcontext будет работать уже другой поток, не тот который был до входа свитчконтекст? Вот это собственно вопрос темы
>>Это сохранение регистров одного потока и восстановление регистров другого. Вот это и смущает, т.к. после сохранения KTRAP_FRAME там регистры другого потока как я понимаю еще не восстанавливаются, а восстанавливаются тоько вконце обработчика
Так и есть - внутри SwitchContext будет перезагружен esp и при возврате из этой функции будет извлечено значение eip уже из "нового" стека, т.е. относящееся к другому потоку. Регистры восстанавливаются, но уже в контексте другого потока. А когда через некоторое время опять получит управление данный поток, регистры будут восстановлены и для него как раз с помощью кода в конце обработчика. Это все очень просто, если смотреть под правильным углом зрения Edited: поправил свой предыдущий пост.
Phantom_84 спасибо. Действительно все несложно, просто в статье как-то кривовато построено повествование о судьбе переключаемого потока, создается впечатление что после swapcontext'а и выхода из прерывания он продолжает выполняться благодаря фразам и т.е. проблемы с русским языком у меня или у автора не знаю.
Ну при аппаратной многозадачности перезагрузка регистров, включая eip, будет выполняться по команде аппаратного переключения задач внутри SwitchContext (например, jmp NEXT_TASK_SELECTOR:?), а при программной явно и плюс загрузка eip по команде ret. Принципиальной разницы здесь нет.
