5-15$ это не копейки. Девайс за 250$ это ~50$ НДС (19% у нас), за 120$ продается оптовым диллером магазину, за 100$ продается оптовому диллеру до перевозки, за 60$ производится, за 40$ в лучшем случае приобретаются компоненты. Лишние 10$ за девайс на производителе, это очень ощутимо.
Также лицензия предлагает кабальные условия (всякие NDA, обязательство на лицензирование других «технологий» в будущем, условия по компонентам и т.п.). 3тье лицо реально лезет к тебе в производственный процесс, делая изменения, что будут стоить тебе кучу денег. Тут далеко не все так просто, заплатил и свободен ;)
Деньги, которые попилит компания, пойдут на помощь в вымогании еще больших денег. Открылся целый рынок «интеллектуальной собственности», куда люди вкладывают деньги, что бы их приумножить на вот таких лицензионных отчислениях. Это рак и он растет. Это плохо. Меняется сознание людей к свободе и здравому смыслу, это еще хуже.
> Для этого есть юристы. Они разбираются в этих вопросах.
Они разбираются в том, что уже «запахло», т.е. дело идет к суду. На момент «давайте сделаем такую фичу» юристы ни в коей мере не знают под какие патенты попадет творение. Нет никакой системы поиска, которая бы «по смыслу» нашла бы патенты. Рыться в этих Овдиевых конюшнях должны инженеры, они больше знают о технических заморочках. Только это гиблое дело, уйдут годы только анализа, любой инженер съедет с катушек, а от бюджета не останется ничего. Сама разработка еще даже не начиналась. За время анализа выйдут в свет новые патенты, что поиск растянется еще на пару лет, пока догонишь эту машину.
Разумеется, что никто в своем уме, не делает столь глубокий поиск по патентам. Посмотрели что есть, вроде все ОК, начали разработку. МС держит патенты в секрете. Да, ты можешь их прочесть, но какие у них патенты, ты не знаешь и они запрещают контрактами со своими жертвами разглашать список патентов. Стратегия в том, что бы не дать тебе найти эти патенты, так что бы ты поработал подольше, что бы и «damages» о которых они заревут, были побольше. Это парни из B&N и называют не честной конкуренцией. А кто прав, решит судья.
> Как только они вырастят первое поколение своих высококлассных инженеров.
Они уже давно учаться в западных университетах. Кстати, трудоголики до фанатизма. У нас в Rijks Universiteit Groningen их много, очень много PhD's. В научных статьях все больше китайских имен. Они уже сейчас разрабатывают электронику сами. BeBook, IBook и куча других брендов стоят за Hanlin eReader, популярная читалка. Компании в других странах все меньше разрабатывают дизайн и софт девайсов, и все больше занимаются просто re-branding'ом и продажей на своей территории.
> иди в суд и аннулируй их.
Это будет длиться годами. У малых предприятий нет десятков миллионов лишних баксов на оплату этой юридической машины. Даже если компания не права, она просто давит своим размером. А потом подымает royalty дабы отбить «убытки».
Для большой компании, у которой четверть штата это юристы, это не плохой способ попилить собственный бюджет, к которому ты так просто прямого доступа не имеешь (акционеры взволнуются). В патентных войнах при любом раскладе выигрывают только юристы, с обоих сторон.
Патентов такое великое море, что там мало кто разбирается + большинство самых грязных патентов находятся годами на регистрации. Глянь на любой современный патент, заявка 2004, выдан в 2010, 6 лет на регистрацию патента — это нормально. За это время никто ничего не знает и разрабатывает свои решения. Затем внезапно патент всплывает и задним числом начинает считать убытки (упущенная выгода, если построить заводы и самому производить/продавать. ключевое слово «если»), от которых и высчитываются штрафы.
Вот как в такой ситуации заранее узнать шансы нарваться на мину? Гугли submarine patents.
Писатели всегда активны. Читайте задачу внимательней. Современные сервисы в сети всегда что-то пишут (eventual consistency) и одновременно копаются в данных. Это уже стандарт. Следовательно проблема с дублированием данных в кеше все еще актуальна.
Переключение в режим ядра не самая большая проблема. Да, это смена контекста, да это задержка, только камни под это оптимизируются. Сложность в scheduler'е, которому предстоит работать со *всеми* потоками в системе, а их много. И идея в том, что реализация удобных легковесных потоков не задача ОС, а задача прикладного run-time. Просто перечтите это утверждение снова, вы поймете)
> Необходимо обеспечить кэширование состояния базы с определённым временным шагом,
Получается в памяти держим индекс дважды, один раз для писателей (хотя им для ребалансировки не нужно все дерево целиком) и еще раз для читателей. При чем читатели обращаются через модуль редиректа (дополнительный модуль/сервис понижает отказоустойчивость системы — он может отвалиться). Это не эффективно, да и грузить индекс в кеш придется постоянно, помним что писатели все время пишут. Наше условие: объект доступен в индексе *сразу* как только писатель закончит (очень важно для всяких stock market).
Выходит общих данных попросту нет. Каждый модуль — это один поток с thread-local переменными. С большим индексом, как я уже описал выше, придется внедрять дублирующий кеш и устаревающими данными, дополнительный IO (а это *очень* дорого) для загрузки данных в кеш, дополнительная сериализация для пересылки thread-local копий данных между модулями. Один только вопрос остался: зачем? Какие преимущества мне даст система, если я таки решу пройти через все эти танцы с модулями, по сравнению с Linux + Python + C-extensions + Lustre?
> Вот именно поэтому проблема по-настоящему не решается с помощью middleware.
Ответ не верный =)
Есть 2 процессора с 4 ядрами каждый, итого можем крутить 8 параллельных задач. Знаем, что два потока на одном процессоре могут быстрей обмениваться данными, через кеш камня. К примеру мютексы будут железными, в сотню раз быстрей, да и много других плюшек. Также современный процессор может иметь состояния и переходить из одного в другое. В разных состояниях имеем какие то дополнительные инструкции и прочие вкусные вещи. Но переключение между состояниями, штука довольно дорогая.
Итог: задача ОС грамотно schedule задачи, учитывая железные особенности для большей производительности.
1) Допустим есть некоторые «железные потоки», их столько же, сколько в железе ядер. Такой поток всегда привязан к одному ядру, он либо работает, либо halt свое ядро и не потребляет энергию.
2) Ниже есть системные потоки, их может быть сколько угодно и они крутятся поверх «железных потоков». Количество системных потоков ограничено производительностью. Есть некоторая индексная структура, в которой описаны все системные потоки, их состояние блокировки, время ожидания, приоритет и т.д. Scheduler с помощью этой индексной структуры выбирает потоки на работу, что будет быстрей, чем перебирать все потоки-кандидаты. Чем больше системных потоков, тем больше индекс, тем больше требуется времени на поиск кандидата-потока, тем больше доля потерянного времени в одном кванте времени отданного потоку. В худшем случае 70% кванта времени будет уходить Scheduler'у, 30% потоку. Очевидно, что скорость работы системы будет не удовлетворительной, хотя утилизация процессора на все 100%. Все блокировки между системными потоками — системные, т.е. на уровне ядра ОС.
3) Народ подумал и решил, ведь большинство блокировок, это ожидание ресурса: сеть, файлы, queue, что угодно. Лишь малая часть блокировок реально системные (критические секции, они обычно мгновенные). Тогда почему бы не сделать кооперативную многозадачность. Если поток знает, что повиснет на IO, то отдав запрос он просто отдает управление любому другом потоку. Это уже все в user-space. Вместо обще-системного списка потоков, у меня теперь маленький список green threads внутри одного процесса. Искать в маленьком списке проще.
Первый уровень требует хорошего знания железа. Второй уровень хорошего дизайна ОС и scheduler'а. Третий уровень прикладной и в принципе не зависит от ОС, ВМ и т.д.
> Поскольку это ОС единого адресного пространства, потоки будут изначально легковесными.
По моему вы несколько не поняли идею green threads. Суть их в не ограниченном количестве без последствий для производительности. Это фактически кооперативная многозадачность поверх блокирующих ресурсов + по наследству принудительная многозадачность за счет пула реальных потоков.
Реальные потоки, какими бы они не были, усложняют работу scheduler'а. Чем их больше, тем больше лаги. Их количество влияет на работу. Их блокировка по прежнему влияет на рабоду scheduler'a. С реальными потоками не так то просто будет ответить за утверждение «что и позволит запускать их тучами». Алгоритмы scheduler'ов процессов/потоков — популярная тема для holy war'ов.
> Тоже касается индекса и репликации — не стоит всё пихать в один модуль.
Э… положить все в один модуль речи не было, как раз наоборот. Есть множество сервисов, которые используют некий общий ресурс, который в силу железных ограничений (память не резиновая) нельзя скопировать для каждого сервиса отдельно. Что бы убрать долгие блокировки на обновления мы оставляем старые ноды индекса (иначе чтение будет не возможным, 99.9% времени мы чего то пишем, следовательно лочим индекс). После того, как ноды больше не используются ни одним из сервисов, их можно выкинуть. Так вот когда их можно выкинуть?
Индекс, в силу своей природы (дерево, постоянная ре-балансировка) нельзя разбить на кусочки и положить в thread-local переменные каждого отдельного сервиса.
А если есть общие данные, которые нельзя держать thread-local эффективно. В комменте ниже я привел пример с файловым индексом, который слишком большой, что бы его копировать для каждого потока. Его и в память то грузить можно только порциями, а потом потоки, как аквариумные рыбки на корм, налетают на отдельные ноды. При чем сам индекс все время меняется, это не мертвый снепшот.
Конечно. Но это не делает утверждение «Без таймера не возможна работа ОС» верным. ОС может использовать разные scheduler'ы процессов, иногда сразу несколько. В малых (железных) проектах preemptive multitasking — штука вредная.
Иногда периферию слушают через polling по таймеру, но это редкость и не имеет отношения к ОС.
У нас есть некоторая документная БД. Есть несколько сервисов, которые постоянно пишут в эту БД, пусть это будет аггрегатор новостей для группы пользователей. Запись очень плотная, 99,9% времени пишущие сервисы активны (к примеру слежение за курсом акций по миру).
Читают БД наоборот не равномерно. То во время перекура ожидаем огромную толпу, то где нибудь к 3 часам дня наоборот тишина, 2-3 тысячи запросов в минуту. Сервис публикуется сразу всем по сети. Естественно, что клиенты не заинтересованы в чистых документах, а уже в готовой инфе. Потому в системе работают не останавливающиеся map/reduce worker'ы, собирающие инфу в разного рода индексы.
Данные хранятся на нескольких уровнях, индексы и свежее на чем то быстром (свои SSD, raid массивы), на чем то среднем (кластер) и на чем то медленном (кассеты). При чем я как разработчик ничего не знаю об этом, это задача ОС/VFS сливать то, что используется редко в более объемное, но медленное хранилище. Это замечание к вашей будущей ОС, а не ВМ.
Потребуются green threads для работы с IO (файлы, сеть, БД). Я просто запускаю новую нить под каждый запрос не задумываясь как это повлияет на системный scheduler. Нет необходимости в thread pools и не блокирующем IO, что очень сильно упрощает работу.
Потоки хоть и green, но будут работать поверх пула реальных потоков, а значит исполнятся параллельно. Следовательно, если есть некий общий ресурс, индексы нашей БД в памяти (они большие, не будем же мы их грузить для каждого потока отдельно), который постоянно обновляется, то нужно разграничивать доступ. Без блокировок я могу пользоваться versioned index, когда деревья перестраиваются, но старые ноды при этом остаются. Это позволяет пишущему процессу обновить индекс, а читающий ничего не заметит, без блокировок (подсмотреть идею можно в CouchDB). С файлами все понятно, оставили ноды на диске, потом какой нибудь vacuum процесс это все подчистит. А как это дело в памяти?
Кратко: есть дерево индексов, на которое ссылается каждый поток. Оно большое и постоянно изменяется, старые ноды остаются в памяти, пока потоки их использующие их не отпустят. Потоки не знают кто еще использует эти ноды, вести прямой подсчет ссылок (взял ноду ++, отдал ноду --) будет крайне накладно из-за постоянной синхронизации, что сведет на нет параллельность выполнения (через 5 лет будем иметь десятки, если не сотни ядер в камне. критические секции станут bottleneck). Как чистить память?
Сборщик мусора имеет время «подумать». Ему нужно поддерживать свободную память в текущей генерации. Пока она есть, не важно сколько времени займет перебор всей памяти во время чистки, и какие трюки будем использовать. Правда и памяти на работу приходиться хапать сразу много, это не путь low memory profile утилит. Сборка мусора — интересный раздел computer science.
Одни и те же вопросы в догонку объясняются в разных ветках… читающим будет смешно))
> у каждого хоста своё адресное пространство.
Вот тут проблема. Каждый хост имеет несколько потоков, ведь он крутиться на многоядерном процессоре. Явная синхронизация при подсчете ссылок сведет на нет производительность. Или какое другое решение?
Вопрос с оптимизацией решен. Но разве LLVM решает за вас остальные проблемы? Как на счет работы с памятью в многопоточном приложении, которые по вашей идее будут работать в одном адресном пространстве?
> она поддерживает то, что с лихвой могут другие виртуальные машины.
Это не правда. Современная ВМ это транслятор в машинный код, с оптимизацией под архитектуру, управление памятью и полный доступ до всех плюшек host-OS. У вас, как мы уже выяснили выше, надежда на LLVM, который будет оптимизировать вашу машину. Не байткод, который вы пока интерпретируете. Переход на трансляцию — это все начать с нуля.
У вас пока нет потоков, семафоров или наоборот чего нибудь посвежее, например выявление side-effect free кода, транзакционной памяти и т.п. Это даже не 1% от всех задач, которые вам еще придется решить. Это как сравнить самокат и машину класса люкс, оба инструмента едут.
> если раньше не потеряю интерес.
Не теряйте, давайте лучше вместе подумаем над вашей ВМ. Начните с примеров приложений, пусть гипотетических, которые будут работать в вашей ВМ, используя все ее преимущества. Затем найдем минимальный набор фич ВМ, которые реализуют эти особенности. Затем под это найдем фичи вашей ОС.
> Это с чего вы взяли невнятность дизайна?
Я не сказал, что дизайн не внятный. Его просто нет. Каюсь, может стоит просто вернуться в этот топик через две недели, когда вы выложите собственно зерно ваших идей, а не банальные детали ВМ, которые мы все видели и писали на втором курсе университета. Тогда извиняюсь если задел.
> построение распределённой среды для клиентских приложений.
Первый же вопрос пока без внятного ответа, как работать с памятью если: 1) у нас одно адресное пространство, 2) у нас много сервисов в многопоточной среде.
По моему вы не правы. LLVM позволяет написать софтину, которая позже на лету себя оптимизирует. Прикладное приложение, с помощью загрузчика и run-time себя оптимизирует.
У вас ВМ, которая себя оптимизирует. И по прежнему на прямую исполняет байткод, разве не так? ;)
Другое дело если вы будете генерить безопасный IF, а кормить его LLVM. Или оно уже так работает?
Также лицензия предлагает кабальные условия (всякие NDA, обязательство на лицензирование других «технологий» в будущем, условия по компонентам и т.п.). 3тье лицо реально лезет к тебе в производственный процесс, делая изменения, что будут стоить тебе кучу денег. Тут далеко не все так просто, заплатил и свободен ;)
Деньги, которые попилит компания, пойдут на помощь в вымогании еще больших денег. Открылся целый рынок «интеллектуальной собственности», куда люди вкладывают деньги, что бы их приумножить на вот таких лицензионных отчислениях. Это рак и он растет. Это плохо. Меняется сознание людей к свободе и здравому смыслу, это еще хуже.
Они разбираются в том, что уже «запахло», т.е. дело идет к суду. На момент «давайте сделаем такую фичу» юристы ни в коей мере не знают под какие патенты попадет творение. Нет никакой системы поиска, которая бы «по смыслу» нашла бы патенты. Рыться в этих Овдиевых конюшнях должны инженеры, они больше знают о технических заморочках. Только это гиблое дело, уйдут годы только анализа, любой инженер съедет с катушек, а от бюджета не останется ничего. Сама разработка еще даже не начиналась. За время анализа выйдут в свет новые патенты, что поиск растянется еще на пару лет, пока догонишь эту машину.
Разумеется, что никто в своем уме, не делает столь глубокий поиск по патентам. Посмотрели что есть, вроде все ОК, начали разработку. МС держит патенты в секрете. Да, ты можешь их прочесть, но какие у них патенты, ты не знаешь и они запрещают контрактами со своими жертвами разглашать список патентов. Стратегия в том, что бы не дать тебе найти эти патенты, так что бы ты поработал подольше, что бы и «damages» о которых они заревут, были побольше. Это парни из B&N и называют не честной конкуренцией. А кто прав, решит судья.
Они уже давно учаться в западных университетах. Кстати, трудоголики до фанатизма. У нас в Rijks Universiteit Groningen их много, очень много PhD's. В научных статьях все больше китайских имен. Они уже сейчас разрабатывают электронику сами. BeBook, IBook и куча других брендов стоят за Hanlin eReader, популярная читалка. Компании в других странах все меньше разрабатывают дизайн и софт девайсов, и все больше занимаются просто re-branding'ом и продажей на своей территории.
Это будет длиться годами. У малых предприятий нет десятков миллионов лишних баксов на оплату этой юридической машины. Даже если компания не права, она просто давит своим размером. А потом подымает royalty дабы отбить «убытки».
Для большой компании, у которой четверть штата это юристы, это не плохой способ попилить собственный бюджет, к которому ты так просто прямого доступа не имеешь (акционеры взволнуются). В патентных войнах при любом раскладе выигрывают только юристы, с обоих сторон.
Вот как в такой ситуации заранее узнать шансы нарваться на мину? Гугли submarine patents.
Получается в памяти держим индекс дважды, один раз для писателей (хотя им для ребалансировки не нужно все дерево целиком) и еще раз для читателей. При чем читатели обращаются через модуль редиректа (дополнительный модуль/сервис понижает отказоустойчивость системы — он может отвалиться). Это не эффективно, да и грузить индекс в кеш придется постоянно, помним что писатели все время пишут. Наше условие: объект доступен в индексе *сразу* как только писатель закончит (очень важно для всяких stock market).
Выходит общих данных попросту нет. Каждый модуль — это один поток с thread-local переменными. С большим индексом, как я уже описал выше, придется внедрять дублирующий кеш и устаревающими данными, дополнительный IO (а это *очень* дорого) для загрузки данных в кеш, дополнительная сериализация для пересылки thread-local копий данных между модулями. Один только вопрос остался: зачем? Какие преимущества мне даст система, если я таки решу пройти через все эти танцы с модулями, по сравнению с Linux + Python + C-extensions + Lustre?
Ответ не верный =)
Есть 2 процессора с 4 ядрами каждый, итого можем крутить 8 параллельных задач. Знаем, что два потока на одном процессоре могут быстрей обмениваться данными, через кеш камня. К примеру мютексы будут железными, в сотню раз быстрей, да и много других плюшек. Также современный процессор может иметь состояния и переходить из одного в другое. В разных состояниях имеем какие то дополнительные инструкции и прочие вкусные вещи. Но переключение между состояниями, штука довольно дорогая.
Итог: задача ОС грамотно schedule задачи, учитывая железные особенности для большей производительности.
1) Допустим есть некоторые «железные потоки», их столько же, сколько в железе ядер. Такой поток всегда привязан к одному ядру, он либо работает, либо halt свое ядро и не потребляет энергию.
2) Ниже есть системные потоки, их может быть сколько угодно и они крутятся поверх «железных потоков». Количество системных потоков ограничено производительностью. Есть некоторая индексная структура, в которой описаны все системные потоки, их состояние блокировки, время ожидания, приоритет и т.д. Scheduler с помощью этой индексной структуры выбирает потоки на работу, что будет быстрей, чем перебирать все потоки-кандидаты. Чем больше системных потоков, тем больше индекс, тем больше требуется времени на поиск кандидата-потока, тем больше доля потерянного времени в одном кванте времени отданного потоку. В худшем случае 70% кванта времени будет уходить Scheduler'у, 30% потоку. Очевидно, что скорость работы системы будет не удовлетворительной, хотя утилизация процессора на все 100%. Все блокировки между системными потоками — системные, т.е. на уровне ядра ОС.
3) Народ подумал и решил, ведь большинство блокировок, это ожидание ресурса: сеть, файлы, queue, что угодно. Лишь малая часть блокировок реально системные (критические секции, они обычно мгновенные). Тогда почему бы не сделать кооперативную многозадачность. Если поток знает, что повиснет на IO, то отдав запрос он просто отдает управление любому другом потоку. Это уже все в user-space. Вместо обще-системного списка потоков, у меня теперь маленький список green threads внутри одного процесса. Искать в маленьком списке проще.
Первый уровень требует хорошего знания железа. Второй уровень хорошего дизайна ОС и scheduler'а. Третий уровень прикладной и в принципе не зависит от ОС, ВМ и т.д.
По моему вы несколько не поняли идею green threads. Суть их в не ограниченном количестве без последствий для производительности. Это фактически кооперативная многозадачность поверх блокирующих ресурсов + по наследству принудительная многозадачность за счет пула реальных потоков.
Реальные потоки, какими бы они не были, усложняют работу scheduler'а. Чем их больше, тем больше лаги. Их количество влияет на работу. Их блокировка по прежнему влияет на рабоду scheduler'a. С реальными потоками не так то просто будет ответить за утверждение «что и позволит запускать их тучами». Алгоритмы scheduler'ов процессов/потоков — популярная тема для holy war'ов.
> Тоже касается индекса и репликации — не стоит всё пихать в один модуль.
Э… положить все в один модуль речи не было, как раз наоборот. Есть множество сервисов, которые используют некий общий ресурс, который в силу железных ограничений (память не резиновая) нельзя скопировать для каждого сервиса отдельно. Что бы убрать долгие блокировки на обновления мы оставляем старые ноды индекса (иначе чтение будет не возможным, 99.9% времени мы чего то пишем, следовательно лочим индекс). После того, как ноды больше не используются ни одним из сервисов, их можно выкинуть. Так вот когда их можно выкинуть?
Индекс, в силу своей природы (дерево, постоянная ре-балансировка) нельзя разбить на кусочки и положить в thread-local переменные каждого отдельного сервиса.
Иногда периферию слушают через polling по таймеру, но это редкость и не имеет отношения к ОС.
Читают БД наоборот не равномерно. То во время перекура ожидаем огромную толпу, то где нибудь к 3 часам дня наоборот тишина, 2-3 тысячи запросов в минуту. Сервис публикуется сразу всем по сети. Естественно, что клиенты не заинтересованы в чистых документах, а уже в готовой инфе. Потому в системе работают не останавливающиеся map/reduce worker'ы, собирающие инфу в разного рода индексы.
Данные хранятся на нескольких уровнях, индексы и свежее на чем то быстром (свои SSD, raid массивы), на чем то среднем (кластер) и на чем то медленном (кассеты). При чем я как разработчик ничего не знаю об этом, это задача ОС/VFS сливать то, что используется редко в более объемное, но медленное хранилище. Это замечание к вашей будущей ОС, а не ВМ.
Потребуются green threads для работы с IO (файлы, сеть, БД). Я просто запускаю новую нить под каждый запрос не задумываясь как это повлияет на системный scheduler. Нет необходимости в thread pools и не блокирующем IO, что очень сильно упрощает работу.
Потоки хоть и green, но будут работать поверх пула реальных потоков, а значит исполнятся параллельно. Следовательно, если есть некий общий ресурс, индексы нашей БД в памяти (они большие, не будем же мы их грузить для каждого потока отдельно), который постоянно обновляется, то нужно разграничивать доступ. Без блокировок я могу пользоваться versioned index, когда деревья перестраиваются, но старые ноды при этом остаются. Это позволяет пишущему процессу обновить индекс, а читающий ничего не заметит, без блокировок (подсмотреть идею можно в CouchDB). С файлами все понятно, оставили ноды на диске, потом какой нибудь vacuum процесс это все подчистит. А как это дело в памяти?
Кратко: есть дерево индексов, на которое ссылается каждый поток. Оно большое и постоянно изменяется, старые ноды остаются в памяти, пока потоки их использующие их не отпустят. Потоки не знают кто еще использует эти ноды, вести прямой подсчет ссылок (взял ноду ++, отдал ноду --) будет крайне накладно из-за постоянной синхронизации, что сведет на нет параллельность выполнения (через 5 лет будем иметь десятки, если не сотни ядер в камне. критические секции станут bottleneck). Как чистить память?
Сборщик мусора имеет время «подумать». Ему нужно поддерживать свободную память в текущей генерации. Пока она есть, не важно сколько времени займет перебор всей памяти во время чистки, и какие трюки будем использовать. Правда и памяти на работу приходиться хапать сразу много, это не путь low memory profile утилит. Сборка мусора — интересный раздел computer science.
Возможна. Небольшие RTOS (под PIC'и к примеру) зачастую используют кооперированную многозадачность. Таймер оказывается не нужен:
— потоки переключаются между собой из вежливости
— периферия вся на прерываниях, никакого polling'а
[offtop]
> у каждого хоста своё адресное пространство.
Вот тут проблема. Каждый хост имеет несколько потоков, ведь он крутиться на многоядерном процессоре. Явная синхронизация при подсчете ссылок сведет на нет производительность. Или какое другое решение?
P.S. просто смотрел изначально на в src/vm/instr.cpp, пока не дошел до эмитеров в mdata.cpp
Это не правда. Современная ВМ это транслятор в машинный код, с оптимизацией под архитектуру, управление памятью и полный доступ до всех плюшек host-OS. У вас, как мы уже выяснили выше, надежда на LLVM, который будет оптимизировать вашу машину. Не байткод, который вы пока интерпретируете. Переход на трансляцию — это все начать с нуля.
У вас пока нет потоков, семафоров или наоборот чего нибудь посвежее, например выявление side-effect free кода, транзакционной памяти и т.п. Это даже не 1% от всех задач, которые вам еще придется решить. Это как сравнить самокат и машину класса люкс, оба инструмента едут.
> если раньше не потеряю интерес.
Не теряйте, давайте лучше вместе подумаем над вашей ВМ. Начните с примеров приложений, пусть гипотетических, которые будут работать в вашей ВМ, используя все ее преимущества. Затем найдем минимальный набор фич ВМ, которые реализуют эти особенности. Затем под это найдем фичи вашей ОС.
Я не сказал, что дизайн не внятный. Его просто нет. Каюсь, может стоит просто вернуться в этот топик через две недели, когда вы выложите собственно зерно ваших идей, а не банальные детали ВМ, которые мы все видели и писали на втором курсе университета. Тогда извиняюсь если задел.
> построение распределённой среды для клиентских приложений.
Первый же вопрос пока без внятного ответа, как работать с памятью если: 1) у нас одно адресное пространство, 2) у нас много сервисов в многопоточной среде.
У вас ВМ, которая себя оптимизирует. И по прежнему на прямую исполняет байткод, разве не так? ;)
Другое дело если вы будете генерить безопасный IF, а кормить его LLVM. Или оно уже так работает?