| OSDev http://osdev.su/ |
|
| Проектирование ОС http://osdev.su/viewtopic.php?f=5&t=495 |
Страница 4 из 9 |
| Автор: | Mr.McD. [ 18 фев 2012, 22:57 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
SII писал(а): Уж теперь моё ЧСВ точно вызовет переполнение, стопудово :))) Лишь бы не во вред.. |
|
| Автор: | Yoda [ 19 фев 2012, 00:06 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Я фигею с вас ))))) Вы что, специально придуриваетесь, что ли?? Сижу и угораю потихоньку. )))))) Mr.McD. Попробуйте написать на ассемблере передачу сообщения от процесса на одном ЦПУ процессу на другом без использования мьютекса (точнее, его ассемблерного эквивалента). Вот когда попробуете, тогда и будете теоретизировать. Станислав То, что вы реализовали, называется кооперативной многозадачностью. Очевидность невероятного в том, что вы доказываете, что у вас нет того, что вы реализовали. ) |
|
| Автор: | Mr.McD. [ 19 фев 2012, 01:19 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Yoda писал(а): Mr.McD. Попробуйте написать на ассемблере передачу сообщения от процесса на одном ЦПУ процессу на другом без использования мьютекса (точнее, его ассемблерного эквивалента). Вот когда попробуете, тогда и будете теоретизировать. А почему не на машинном коде? - Может это ещё лучше раскроет смысл мутекса? Мутексы нужны для исключения совместного доступа нескольких потоков к одному ресурсу. Обменом сообщениями занимается ядро системы. Т.е., если к обмену сообщениями "за уши " притянуть тему мутекса, то к чему взаимный доступ нужно исключать? К ядру что ли? Так доступ и так исключен запретом ядра на повторную входимость в него. Т.е. отправка сообщения выполняется "атомарно", внутри ядра, и нет смысла исключать к чему либо доступ, примитивом типа мутекса - всё и так уже исключено. При чём тут ассемблер? Yoda писал(а): Станислав То, что вы реализовали, называется кооперативной многозадачностью. Очевидность невероятного в том, что вы доказываете, что у вас нет того, что вы реализовали. ) Ну.. есть немного. Смотрю, ты тоже можешь нормально троллить:))) |
|
| Автор: | Станислав [ 19 фев 2012, 06:23 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
У меня нету многозадачности по таймеру и процесы я не разбиваю, а многозадачность есть дже в системе векторов прерывания, где есть приоритеты задачам, в контролерах есть списки задач для винтов, флешек, ... и много где ещё |
|
| Автор: | Mr.McD. [ 19 фев 2012, 06:35 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Станислав писал(а): У меня нету многозадачности по таймеру и процесы я не разбиваю, а многозадачность есть дже в системе векторов прерывания, где есть приоритеты задачам, в контролерах есть списки задач для винтов, флешек, ... и много где ещё Если и дальше проводить подобную аналогию, то многозадачной нельзя назвать ни одну систему, работающую на одном процессоре. Всё же, за данным подходом закрепился свой ярлык: кооперативная многозадачность. Станислав, а расскажи немного о системе своей. Собственно интересно (можно в двух словах): 1. Как происходит загрузка программ в память? 2. Как взаимодействуют программы? 3. Как работает планировщик? |
|
| Автор: | pavia [ 19 фев 2012, 08:32 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Цитата: А почему не на машинном коде? - Может это ещё лучше раскроет смысл мутекса? Мутексы нужны для исключения совместного доступа нескольких потоков к одному ресурсу. Обменом сообщениями занимается ядро системы. Т.е., если к обмену сообщениями "за уши " притянуть тему мутекса, то к чему взаимный доступ нужно исключать? К ядру что ли? Так доступ и так исключен запретом ядра на повторную входимость в него. Т.е. отправка сообщения выполняется "атомарно", внутри ядра, и нет смысла исключать к чему либо доступ, примитивом типа мутекса - всё и так уже исключено. При чём тут ассемблер? Если раньше считал что Mr.McD. не понимаю потому что чего-то не знаю. Так теперь видно что он просто глупец. Ассемблер нагляднее машинного кода. А в виду того что это примитивный язык, то будет видны все недостатки блокировки. |
|
| Автор: | Станислав [ 19 фев 2012, 09:47 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Моя система грузит с флешки 5500 секторов, там код, картинки. В коде функции для отрисовки графики, векторных шрифтов, иконок прозрачных с тенью, линии безъе, ... . Создаётся массив с объектами (иконки, формы, компоненты на форме, ...), и при отрисовки объектов в 4й байт пикселя записывается его номер, при нажатии мышкой, или просто движение на нем по этому номеру берётся из массива функция обработки событий и вызывается, после первого вызова она становится активной и туда же идут сообщения от клавы, таймера и все остальные. Если эту функцию ставят в массив на постоянные события то туда постоянно идут сообщения от таймера но с другим параметром (например тип сообщения 9). Например драйвер фат32 у меня сразу создаёт объект иконку с текстом (именем файла) и функцией обработки событий, если это папка то при нажатии опять запустится функция создания объектов в этой папку, если файл то функция чтения его в память. Сама форма может не обрабатывать компоненты, они сами по себе живут на ней и получают сообщения какие им надо, а форма хранит их изображение при отрисовки перемещения, активации. В массив заносятся только те компоненты, которые видны на экране. Создал пока только заготовки для драйверов контролеров дисков юсб аудио. Кстати сейчас интел систематизировала работу всех устройств в современные контролеры и не нужно писать драйвер для конкретного устройства, 30 разных звукавух работают с контролером одинаково и не важно какой комп, если там контролер hda то драйвер для всех звуковух только один. Это для всех устройств кроме видео. В Анонсы проектов - Новая ОС есть описание и скриншот. |
|
| Автор: | Yoda [ 19 фев 2012, 13:16 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Mr.McD. писал(а): Обменом сообщениями занимается ядро системы. Т.е., если к обмену сообщениями "за уши " притянуть тему мутекса, то к чему взаимный доступ нужно исключать? К ядру что ли? Так доступ и так исключен запретом ядра на повторную входимость в него. Вы же причисляете себя к ось-девелоперам, то есть разрабатываете ядро системы. Вот и расскажите мне, безграмотному, как в ядре осуществляется запрет на повторную входимость в него. А точнее, запрет на выполнение функции одним процессором, пока её выполняет другой. :) |
|
| Автор: | Mr.McD. [ 19 фев 2012, 17:44 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
pavia писал(а): Если раньше считал что Mr.McD. не понимаю потому что чего-то не знаю. Так теперь видно что он просто глупец. Ассемблер нагляднее машинного кода. А в виду того что это примитивный язык, то будет видны все недостатки блокировки. Первоклассный понос мыслей. Упячка одобряе... Yoda писал(а): Вы же причисляете себя к ось-девелоперам, то есть разрабатываете ядро системы. Вот и расскажите мне, безграмотному, как в ядре осуществляется запрет на повторную входимость в него. А точнее, запрет на выполнение функции одним процессором, пока её выполняет другой. :) Делается это так: за критическим участком кода закрепляется свой флаг занятости (переменная). Каждый поток, перед тем, как войти в критическую секцию крутится в бесконечном цикле, ожидая освобождения флага. Если флаг свободен - атомарно его устанавливает в состояние "занято" (для х86 - xchg), и заходит в КС. По выходу из КС - сбрасывает флаг. Данный подход называется - спинлок. Код: //Устанавливаем параметры фага. mov eax, адрес_флага mov ebx, занято //Крутимся в цикле. wait_cycle: lock xchg [eax], ebx cmp ebx, свободно jnz wait_cycle ...Работаем в КС //Сбрасываем флаг. mov eax, адрес_флага mov ebx, свободно lock xchg [eax], ebx Если передача сообщения выполняется быстрее, чем переключение контекста, то следует применять спинлок, а не мутекс (что обычно и делают). Но ни спинлок, ни мутекс не имеют прямого отношения к обмену сообщениями, ибо последний - самостоятельный высокоуровневый механизм обмена данными и синхронизации, со своими плюшками. Только не говори, что ты не знал..) Станислав, очень своеобразная у тебя система... |
|
| Автор: | Yoda [ 19 фев 2012, 18:13 ] |
| Заголовок сообщения: | Re: Проектирование ОС |
Спасибо, что просветили! :))) Спинлок или мьютекс - это частности. А вот фраза "самостоятельный высокоуровневый механизм" осталось немножко мутновата для меня. Не хотите ли вы сказать, что обмен сообщениями никак не использует мьютексы, спинлоки и прочие типы семафоров? Тогда что вы мне объясняли? Кстати, перед командой xchg не обязательно ставить префикс lock. См. страницу 365 второго тома руководства Интела по системе команд. Эта инструкция атомарная от природы. |
|
| Страница 4 из 9 | Часовой пояс: UTC + 3 часа |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|