nkulikov2Onstat: Я бы так не утвержадл, что нити Informix полностью все всебе и ничего общего с OS не имеют. Я помню баг на солярке когда реализации некоторых функций связанных с pthread находились в разных библиотеках в разных директориях. И в зависимости от того какой путь был высавлен в переменных окружения informix
типа /usr/lib:/usr/share/lib или /usr/share/lib:/usr/lib разница в производительности составляла 20%

Это правда косяк Solaris был.


Таки да, нити сервера информикса реализованы собственной библиотекой и ничего общего с pthreads не имеют. На вопрос "почему ?" говорили - чтобы не зависеть от пятнадцати производителей OS и не ждать, пока они соизволят пофиксить несовместимости и баги.
В приложениях , разработанных с informix SDK - там, действительно, можно использовать OS pthreads.

GVF112GVFУважаемые коллеги,
насколько я помню, есть всего три способа реализации потоков для разных операционных сред:

1. Реализация потоков в пространстве пользовательского процесса. В данном случае, ядро ОС о потоках ничего не знает и управляет обычными, однопоточными процессами. Управление потоками на себя берет прикладной процесс (INFORMIX).

Именно такая модель реализации потоков, использовалась в ранних версиях INFORMIX
для операционных сред, которые не использовали реализацию потоков на уровне ядра системы (или где потоков не было по определению) - SCO UNIX, ранний LINUX и т. д.

Поэтому, инженеры INFORMIX, реализовали, собственную систему управления потоками внутри пользовательского процесса.

Для использовались разные языки программирования.
Как правило – это язык С, который включал для различных платформ ассемблерные вставки, которые использовались для эффективного управления потоками и mutex на аппаратном уровне процессора.

Далее, кроме языка С, использовался язык Yacс … для реализации Syntax Parser SQL и т.д.

2. Реализация потоков на уровне ядра операционной системы.
Понятно, что в данном случае, планировщик ОС управляет потоками по требованию прикладного процесса.

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

Ошибка в реализации системных функций (в системных библиотеках), могут прямо или косвенно повлиять на функциональность работы всего приложения (INFORMIX) и т.д.

3. Смешанная реализация – мультплексирование потоков пользовательского процесса из потоков ядра.

По всей видимости, данный подход реализован для INFORMIX на платформе WINDOWS,
и возможно SUN SOLARIS. Где потоки процесса ядра INFORMIX отображаются на системные потоки ОС и т.д. В этом случае, ошибки могут быть где угодно ... 

Теперь о языках программирования.
Так как средства компиляции достигли значительных результатов .... компиляторы стали умнее .. а вести разработку удобнее на OO- языке, то в качестве основного языка, по всей видимости, был выбран C++. Хотя никто не отменял многоуровневую архитектуру, модульность в реализации проекта с элементами оптимизации (некоторые модули могут быть реализованы на C и ассемблер , другие на C++ - SQLI-протокол , поддержка UNICODE и т.д.).

С уважением,
Вадим.

Уважаемый коллега,
вы, конечно, можете как археолог восстанавливать "методы, принятые в ранних версиях", и "основной язык, по всей видимости выбранный" :-) - но я в свое время этот информикс немножко компилировал и баги фиксил. Нет там в ядре никакого C++. И нити реализованы собственной библиотекой, без помощи ОС.
В таком вот аксепте.