Название немного провакационное, но другого я не смог придумать   собственно вот в чем вопрос:
я много раз слышал, от разных людей, что linux якобы имеет лучшую чем windows архитектуру и производительность, и больше подходит для создания высоконагруженых высоконадежных серверных приложений, работающих в режиме 24х7 годами без перезагрузок ну и тд. В детали никто не углубляется, все просто говорят что это так. В общем мне интересно откуда такие выводы, мне интересны именно отличия с точки зрения программиста. То-есть отличия в реализации многопоточности, асинхронных операций, подсистемы ввода вывода, стандартных библиотек, и чем posix api лучше windows api =) желательно со ссылками. GUI здесь не обсуждаем. 
Желающие покричать linux(windows) рулед а все остальное ### идут лесом.  

Ну вот линуксоиды часто критикуют API CreateProcess за польшое число аргументов, а сами в такой ситуации клонируют процесс, а потом грузят в клон другой модуль. Вот такая модель.   

Ужас...

1. многопоточность
начнем с того, что в Linux нет потоков как отдельных сущностей (объектов) ядра
есть объект дескриптора процесса (struct task_struct)
группы таких процессов образуют т. н threads groups, каждая со своим лидером
лидер ничем не отличается от остальных процессов за исключением того, что дескрипторы всех остальных процессов содержат указатель на дескиптор лидера
все дескрипторы грыппы объединены  в список с возможностью доступа из каждого дескриптора ко всем остальных из группы (важнейшая из реализаций NPTL)
семантика потока реализуется через подсчет ссылок на различные ресурсы (в частности виртуальное АП)
в Linux процесс и программа - независимые сущности в рамках API (однако с т. з реализации программа - ресурс процесса)
в Windows CreateProcess изначально привязывает программу (исполняемый файл) к процессу
поэтому семантика fork'а не реализуема и это минус
чем меньше сущностей - тем лучше и прозрачнее конечная система, поэтому разделение на потоки и процессы мне не кажется удачным решением (в итоге результат все равно один)
в Linux модульная реализация планировщика
за модульность отвечают три элемента: структура очереди выполнения (struct rq), класс планирования (struct sched_class) и функция schedule
rq инкапсулирует очереди выполнения, специфичные для конеретного sched_class'а
sched_class инкапсулирует адреса функций, реализующих конкретный тип планировщика
добавление новых стратегий не затрагивает код планировщика (schedule и набор вспомогательных функций)
это плюс
2. асинхронность
здесь все хуже (конечно, если имеется в виду реальная модель асинхронного I/O)
реализация (fs/aio.c) достаточно интересна
применяется комбинированный подход
с одной стороны работают процессы ядра aio (их число равно числу логических процессоров в системе), которые являются обычными work-процессами с очередями, в которые помещаются объекты, описывающие отложенные действия (в данном случае функции чтения/записи), т. е концепция опроса
с другой стороны может использоваться концепция нотификации, когда объект, на который направлена операция асинхронного I/O, уведомляет ядро реализации асинхронного I/O (fs/aio.c) о том, что операция может быть осуществлена
в реальной жизни эта модель I/O поддерживается лишь на уровне невиртуальных ФС
на уровне сокетов, к сожалению, она не поддерживается, это минус

потом еще что-нибудь напишу

Добавлено через 10 минут и 39 секунд
что касается высокопроизводительных сетевых приложений, то они реализуются в основном (за отсутствием асинхронности для сокетов) на неблокирующем I/O и epoll'е
в Windows скорее всего что-то подобное должно быть (если я не ошибаюсь I/O completion port)
вопрос лишь в том, где это реализовано эффективнее и логичнее
я собственоручно изучал код epoll'а и могу с уверенностью сказать, что там практически не к чему придраться, ни одной лишней строчки
опять же в основе всего лежит принцип нотификации

да, предлагаю сделать эту тему показательной и не опускаться на уровень "у кого длиннее"
только объективные аргументы (исходник, документация, man, и т. д) и только с т. з программирования

кто будт оффтопить, будет получать от меня минусы  

Добавлено через 1 минуту и 20 секунд

верно
а представь обратну ситуацию  

Добавлено через 7 минут и 7 секунд

залог такой работы - внутренняя простота и логичность ядра
можем взять любую подсистему и рассмотреть подробнее

  

эээ
дискуссия заглохла?   

изначально, тема создавалось для "у кого длинее", никто не ожидал что ты придешь и напишешь такое, так еще и предупредил по этому поводу...  

ЗЫ: Сорри за оффтоп)) 

Это сообщение отредактировал(а) krwlr - 14.12.2008, 17:14

это такая попытка взять на слабо?  


остается сделать вывод, что архитектура не самая продуманая   
у мелкомягких все несколько более продумано, есть процесс, который не тоже самое что у вас, а просто набор ресурсов, с ним могут быть ассоциированы различные объекты ядра(потоки, файлы, пайпы итд), аттрибуты безопастности, ну естественно один или несколько потоков, так-же процесс получает в момент запуска копии переменных окружения и свои параметры командной строки. Тоесть можно сказать, что поток это не что-то такое абстрактное, а просто загруженое в память приложение. Ну а поток это то, с чем работает планировщик задач. Для 99.9% приложений эта модель проще и логичней. Ну а семантика форк лично мне еще не разу не показалась полезной или удобной. Кстати процессы можно объединять в job-ы и работать с несколькими процессами как с одной сущьностью. Ну и еще существует Thread Pool API  . Еще у нас есть фиберы! Они похожи на green threads в джаве.

И кстати, как в linux работает кэширование файлов?
по поводу асинхронных операций.
В windows, для этого используются порты завершения(iocp). Можно связать порт завершения с объектом ядра, скажем файлом, событием или сокетом а так-же привязать к этому объекту любые данные. И далее, любое событие, связаное с этим объектом(завершение операции чтения или записи, новая порция данных в сокете или переход в сигнальное состояние события) будет поставлено в очередь порта завершения. Рабочие потоки просто ожидают очередной пакет завершения и обрабатывают его. 
Все унифицировано и хорошо масштабируется.   

в Linux аналогично: процесс - набор ресурсов, однако кроме всего прочего - единица выполнения (schedule entity)



процесс наверное имелся в виду, а не поток?
это минус, т. к получается, что программа не есть ресурс процесса и для того, чтобы выполнить программу - необходимо создание нового процесса, что есть оверхед



как насчет перенаправления I/O через каналы?
меня интересует вопрос, каким образом реализована (и реализована ли вообще) эта концепция в Windows без fork-семантики?




это было еще в UNIX с незапямятных времен   
даже еще круче, кроме групп процессов есть сессии, являющиеся контейнерами для групп процессов

да, очепятка


это как?

Насколько я помню, в параметрах CreateProcess можно указать дескрипторы, которые будут служить ему stdin/stdout/stderr, а также указать, что порождаемый процесс унаследует все дескрипторы текущего. Точно так же существуют каналы (pipes). То есть шелл, исполняя конвейерную конструкцию, по идее должен создать канал, затем процессы, которым надо сообщаться, передав им этот канал как stdin/stdout.

очень просто
начнем с того, что на уровне исполнительной подсистемы реализована VFS, абстрагирующая операции I/O от фактической реализации файловых систем (как виртуальных, так и физически связанных с блочным устройством)
VFS определяет 4 структуры данных - super, inode, dentry, file
каждый объект (в том числе обычные файлы), реализующий файловую семантику, определяется структурой inode
эта структура инкапсулирует объект address_space, которая поддерживает кэш физических страниц с данными файла
(реализация - radix_tree)
в структуре address_space определяется структура, которая содержит адреса обработчиков операций с кэшем
readpage, writepage и т. д
т. е каждый файл теоретически может поддерживать свою собственную реализацию кэша
однако ядром предоставляется общая реализация кэша (через объект этой структуры), которую используют большинство ФС
итак, последовательность действий open -> write
1. осуществить resolving пути, переданного в open (найти dentry в dcache или вызвать lookup-callback в inode_operations родительского каталога)
2. dentry однозначно определяет inode, inode определяет address_space, address_space определяет операции с кэшем
3. вызвать обработчик writepage
4. общая реализация writepage ищет в radix_tree физическую страницу, которая соответствует текущему смещению в файле
если страница найдена - осуществляется запись в память и страница помечается как dirty (процессы ядра pdflush позже осуществляют write-back страниц на диск)
если страницы нет в кэше - инициализируется операция I/O на ее чтение
после чтения, она добавляется в кэш

Добавлено через 2 минуты и 16 секунд
Void, 
ну видишь, дополнительное притягивание за уши
понадобиться еще что-то - добавим новый параметр в CreateProcess...
криво

только рабочие потоки опять не в тему
задача асинхронного I/O выполнять операции I/O и сигнализировать об их окончании
причем для этого должна применяться lazy-стратегия, а именно - избежание выполнения ненужных операций
мы должны указать, как именно мы хотим получить уведомление и хотим ли вообще и все
в этом плане в POSIX AIO предусмотрено 2 вида уведомления: создание потока, генерация сигнала
естественно, остается возможность ручного вызова aio_status когда это необходимо 

тоесть кэшем можно управлять, я правильно понял?

Добавлено через 29 секунд
если это так, то это действительно реальное приемущество...

Добавлено через 2 минуты и 40 секунд

так оно и есть, не это твое дело, что и как ты будешь обрабатывать