Yo.!Выбегалло
Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.
а есть нормальный документ описывающий, что там есть и чего нет ?


http://docs.rinet.ru/InforSmes/ch07/ch07.htm#Heading7
автор

The VP holds the same responsibilities that the UNIX operating system has, managing time slices and the priority levels of the jobs allowed to run on the CPU. The VP manages the priority and scheduling of the threads connected to it. VPs are also responsible for switching threads when needed. Figure 7.6 shows a VP switching the context of two threads.

Figure 7.6.
Context switching performed on two threads by a virtual processor.

Threads are not restricted to work under a specific time slice as CPU processes are. A thread continues processing in the VP until it completes its task or until it must wait for something else to occur before it can continue. These waits are built into the thread's instructions, usually to take care of reads or writes or to free up locks. The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

Three types of queues hold the threads not running for each VP class. The ready queue is where all threads that are ready to run reside; that is, they have all the data needed to perform their task. The sleep queue is where threads that have no work to perform reside until there is work for them to do. The wait queue is where threads are placed when they need something else to complete before they can continue. Threads in sleep and wait queues are placed in the ready queue when they are needed to run again.

When there is more than one VP of the same class running, there is still only one set of queues. A thread waiting in the class queue is run on the first VP available. This provides a balance in the workload of each VP and provides faster work throughput of ready threads.

Multiprocessor systems also provide the capability to perform some tasks in parallel. Usually a client process has one session thread associated with it at one time. Tasks that require index building, sorting, sequential scanning, and joining can have more than one session thread. Figure 7.7 shows a client process with more than one session thread attached to various VPs. An example is when a client process reads through table data sequentially. If this table is fragmented over different disk partitions, a thread to read each partition's data can run at the same time. After all the partition reads are complete, the data is placed together by one thread and returned to the client. This process is also known as fan-out, where the single starting point of the fan is at the client. The fan becomes wider as multiple threads are created and connect to multiple VPs. Each of these VPs then connects to multiple CPUs.



Yo.!
а то onstat- нам рассказывал ровно противоположное.


Не надо придумывать.


Yo.!
ВыбегаллоА вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи.

Суть вопроса не сколько в скорости переключения в сумме времени потраченной на все переключения. (см. выделенный фрагмент цитаты)
Нет смысла выделять некоторому коду CPU, если через несколько тактов снова нужно будет делать переключение. Ссылки для понимание этого вопроса я уже здесь приводил.


Yo.!
а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).

Это ваши фантазии, ссылки на документы давайте.

Зл0й

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.


в качестве изучения истории, кто это был ?
ссылки можно ?

Зл0й
Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.

ИМХО если бы все было написано по одной спецификации, то IBM не составило бы труда
взять из Informix все лучшее и перенести в DB2 как изначально планировалось,
но этого не произошло.
Развитие было притормозилось( с 2000 до 2004) , но потом ( после 2005 года) продукт
(технология Informix DSA ) продолжала не просто жить,
а и интенсивно развиваться. Настоящий топик тому доказательство.

Yo.!
а есть нормальный документ описывающий, что там есть и чего нет ?



вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex

Yo.!onstat- The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

ну это рекламный слоган, типа шелковистых волос, никакой информации не несет :(


Какая вам еще нужна информация?
Поставьте Informix и поробуйте, почитайте матчасть и многие вопросы сами собой отпадут.

Yo.!
onstat-
вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex
это уже лучше, но скуповато, описания каких-либо оптимизаций не нашел. зато нашел:
onstat-
Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).

One of the more common ways to use a semaphore is to put a process to sleep on the semaphore waiting for a particular event to wake it up. Informix uses semaphores in this way for a VP process that does not have any further work to do.


почему вы думаете что взвыедение семофоров ОС для оракла дороже чем та же операция в информикс ?


Потому что количество CPU VP равно или меньше количеству физических процессоров или ядер
( так рекомендует performance guid).
при этом эти CPU VP обрабатывают десятки, сотни или тысячи пользовательских сессий.

В Oracle didicated процесс(нить) обслуживает только одну сессию, а их ( dedicated) также
десятки , сотни или тысячи, для соизмеримых систем.
Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.
Хотите доказать обратное, приведите ссылку как Oracle синхронизирует доступ к разделяемым ресурсам dedicated процессов без использования системных вызовов.


Yo.!

ну и дальше:
This spinning is a tight loop in the code that does nothing. Every so many loops it would try for the latch again. This is more CPU intensive, but requires less operating system overhead than swapping the process in and out as it goes to sleep on the semaphore.

ничего не напоминает ? ну и чем это лучше ораклового _spin_count ? к стате сразу вопрос - как завется аналог _spin_count в IDS ?

Такие ситуации бывают редко, но бывают.
Вы их на практике видели?

Вот ответ на ваш вопрос:
автор The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.

Вы _spin_count, вы ведернули из контекста, при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.
Увеличивайте количество LRU, тем самым уменьшите спины.
Если есть не нагруженные CPUVP - остановите их это тоже уменьшает спины.