Битых 2 часа читал вашу статью, так и и не понял в чем вопрос)
здесь www.w3.org/Style/Examples/007/units.en.html написано что требование к пикселю быть размером 1\96 дюйма относится ко всей печатной продукции, ни про какакие мониторы речи нету.
здесь msdn.microsoft.com/ru-ru/library/ms537660.aspx написано что размер пикселя зависит от устройства, что совпадает с данными из первой ссылки.Здравый разум тоже подсказывает пиксель в CSS всегда был и есть пикселем на устройстве.Его размер зависит от размера и характеристик устройства и включенного графического режима.
Тоесть пиксель на устройстве это всегда пиксель CSS.Полпикселя можно реализовать используя субпиксели, но их число, и метода доступа к ним — специфично и в css не рассматривается.Вообщем это чит.
Прежде всего спасибо за заботу о системных программистах, но пожалуйста, сделайте что нибудь другое)Потому что планировщика в операционной системе может и не быть в принципе, это, и тактика навязывания рамок как аппаратный обмен сообщениями успеха в будущем точно не принесет.
Немного размышлений:
1.Например потому что уже существует в архитектуре spark, правда там происходит не обмен сообщениями между задачами, а обмен окнами между юнитами (Integer Unit), которые также можно крутить между задачами инструкциями save\restore, подробностей не знаю, но идея обменивать данные регистров при переключении похожа на вашу.Тоесть уже существует, но там уже «планировщику» нужно прокрутить регистровое окно, чтобы оно из одного треда перекочевало в другое.
2.Интересное получается кино… одна задача исполнила инструкцию передачи сообщения, по вашем следует то что она либо остановится на таймаут, либо сделает исключительное программное переключение через планировщик, а иначе как понять какая из 10 заблокированных ожидающих задач приоритетнее? допустим планировщик тут же передаст управление смежной из этой сладкой парочки задаче, та дойдет до инструкции приема через полчаса работы, и допустим у операции не кончилось время.Простейшая передача блока данных сообщений превратилось в ожидание задачи в полчаса времени! или вообще накрылась медным тазом т.к. таймат истек и обе задачи в недоумении, куда это годится, да, вы можете не останавливать первую задачу а продолжить ее исполнение, но увы, у вас нет механизма транзакционной памяти, как например у интел, процессор которой в случае блокировки по ресурсу (у них память а не буфер, что не меняет сути) смотрит на инструкцию которая для него промаркирована, у вас это получается отдельная инструкция и запоминает адрес для возврата.
3.Может стоить придумать обмен не «сообщениями» а данными произвольного размера через общую память и задачи не блокировать?
4.Хорошо придумано то что передаваемые данные скрыты от других задач и появятся точно у адресата.
5.Инструкция Idle, вход в планировщик, а если у меня 18 диспетчеров и в любой нужно зайти при каких то обстоятельствах c прикладного кольца, чтобы не делать лишние прыжки? тогда для idle нужен аргумент, в таком случае чем она отличается от syscall\sysexit?
6.Мое личное мнение что нужно больше уделять вниманию не инструкциям а архитектуре, ведь полно чего еще не придумали в моделях памяти, распределении данных и задач.
здесь www.w3.org/Style/Examples/007/units.en.html написано что требование к пикселю быть размером 1\96 дюйма относится ко всей печатной продукции, ни про какакие мониторы речи нету.
здесь msdn.microsoft.com/ru-ru/library/ms537660.aspx написано что размер пикселя зависит от устройства, что совпадает с данными из первой ссылки.Здравый разум тоже подсказывает пиксель в CSS всегда был и есть пикселем на устройстве.Его размер зависит от размера и характеристик устройства и включенного графического режима.
Тоесть пиксель на устройстве это всегда пиксель CSS.Полпикселя можно реализовать используя субпиксели, но их число, и метода доступа к ним — специфично и в css не рассматривается.Вообщем это чит.
Немного размышлений:
1.Например потому что уже существует в архитектуре spark, правда там происходит не обмен сообщениями между задачами, а обмен окнами между юнитами (Integer Unit), которые также можно крутить между задачами инструкциями save\restore, подробностей не знаю, но идея обменивать данные регистров при переключении похожа на вашу.Тоесть уже существует, но там уже «планировщику» нужно прокрутить регистровое окно, чтобы оно из одного треда перекочевало в другое.
2.Интересное получается кино… одна задача исполнила инструкцию передачи сообщения, по вашем следует то что она либо остановится на таймаут, либо сделает исключительное программное переключение через планировщик, а иначе как понять какая из 10 заблокированных ожидающих задач приоритетнее? допустим планировщик тут же передаст управление смежной из этой сладкой парочки задаче, та дойдет до инструкции приема через полчаса работы, и допустим у операции не кончилось время.Простейшая передача блока данных сообщений превратилось в ожидание задачи в полчаса времени! или вообще накрылась медным тазом т.к. таймат истек и обе задачи в недоумении, куда это годится, да, вы можете не останавливать первую задачу а продолжить ее исполнение, но увы, у вас нет механизма транзакционной памяти, как например у интел, процессор которой в случае блокировки по ресурсу (у них память а не буфер, что не меняет сути) смотрит на инструкцию которая для него промаркирована, у вас это получается отдельная инструкция и запоминает адрес для возврата.
3.Может стоить придумать обмен не «сообщениями» а данными произвольного размера через общую память и задачи не блокировать?
4.Хорошо придумано то что передаваемые данные скрыты от других задач и появятся точно у адресата.
5.Инструкция Idle, вход в планировщик, а если у меня 18 диспетчеров и в любой нужно зайти при каких то обстоятельствах c прикладного кольца, чтобы не делать лишние прыжки? тогда для idle нужен аргумент, в таком случае чем она отличается от syscall\sysexit?
6.Мое личное мнение что нужно больше уделять вниманию не инструкциям а архитектуре, ведь полно чего еще не придумали в моделях памяти, распределении данных и задач.