OSDev

По-моему, проблема высосана из пальца. Если так важна производительность индивидуального процесса и его потоков -- используйте соответствующие алгоритмы диспетчеризации и назначайте правильные приоритеты. Если же важна производительность системы в целом, а не отдельных задач, то какая разница, сколько одному из потоков придётся ждать? Всё равно работа делается, ведь её должны делать все. Или в Вашем примере только потоки А и Б делом занимаются, а остальные онанизмом? Но в таком случае их попросту не должно быть.

На самом деле и поток А доделывает свою работу только после прохода С-F, всё вполне симметрично, без изгибов и перекосов.
Вообще я не вижу нарушения принципов разделения времени одного процессора на несколько потоков.
Это падение производительности в 6 раз каждого потока в сумме даёт единицу. Тоесть, реальных потерь нет.
А с точки зрения оптимизации, напрашивается увеличение длительности кванта для потока А, или вообще отмена квантования (прерывания) этого потока. Что-то вроде кооперативной многозадачности.
Что касается полезности механизма приоритетности, то он особо проявляется при использовании так называемой динамической приоритетности. Наподобии упоминаемого алгоритма инверсии приорита. Например, можно динамически повышать приоритетность потока, которого ожидают другие потоки (можно даже по количеству ожидающих).

chizh, попробуйте самостоятельно решить этот вопрос. Вот задачка. Решайте её так, как посчитаете нужным. Это не должно занять более минуты)
Есть процесс. В рамках этого процесса исполняются два потока (Ж и П). Ж читает данные из файла. П - гадит в порт принтера. Т.е. Ж читает, передаёт П, а П - гадит)
Естественно они обмениваются данными синхронизированно.

Дано:
Всего потоков в очереди - 127.
Квант времени -15мс.
Чередование - строгое (П следом за Ж)

Вопрос 1.
Сколько пройдёт времени, с тех пор, как прочитаные из файла данные попадут в порт принтера?
а) Если Ж успел отдать мутекс, когда писал П.
б) Если Ж не успел.
в) Какова разница в результатах.

(Временем переключения контекста, чтением файла и записью в порт можно принебречь).

Напишите, сколько получилось))))

Перецитирываюсь: То, что для "А" заняло на один такт (квант) времени больше, то для "В" заняло 6! тактов, т.к. пришлось пропустить всю очередь.
Пардон)) Разумеется я глупость сморозил.
Видимо, так правильно=> Из-за того, что А малость не успел - В пол дня в очереди простоял, а в итоге оба пострадали))

Получилось 127*15мс. Да, таковы принципы разделения времени (если говорить о жёстком разделении времени). Свои идеи по оптимизации я уже высказал, идей больше нет.

Ещё раз: проблема высосана из пальца. Все потоки, существующие в системе, должны быть выполнены, поэтому в общем случае не играет роли, в каком порядке они будут выполняться и сколько времени займёт выполнение одного отдельно взятого потока -- важно лишь то, что должны быть выполнены все потоки и ни один поток не должен захватывать процессор на слишком долгое время, останавливая тем самым работу других потоков. Ну а если существуют критичные к времени выполнения задачи, то надо использовать соответствующие алгоритмы диспетчеризации. Например, в ряде систем квантование времени использовалось лишь для задач, чей приоритет находился в определённом диапазоне. Если в системе существовали более приоритетные задачи, они занимали процессор столько времени, сколько им необходимо -- ОС не снимала их до тех пор, пока они сами не переходили в ожидание или не завершались. Естественно, подобные задачи могли заблокировать выполнение всех остальных задач, но здесь уж дело программиста, как распределить приоритеты и как написать задачи корректно, чтобы подобного не случалось.

Уважаемый chizh, а ведь на практике приходится иметь дело с гораздо большим числом потоков и обмениваться данными нужно всем. И если в системе имеет место взаимоисключение (а в микроядрах они частые гости), то каждый раз необходимо изменять приоритеты? А какой толк от этого, если взаимоисключение уже произошло - приблизить хвост очереди? Возможно. К тому-же стоит повысить приоритеты одной половине потоков, как взаимоисключения начнёт создавать другая. А если и увеличивать квант времени, то увеличивать его всем. Это, несомненно, приведёт к повышению эффективности всей системы вцелом, но уменьшится время отклика, и пропадает та привлекательность разделения времени. Если Вы считаете, что падение производительности процесса(ов) в 63.5 раз - это что-то значит, то решение этой проблемы, действительно хороший вопрос)))

SII, если Вы заметили, то я ПЫТАЮСЬ различать диспетчеризацию и взаимные исключения, которые прямо говоря имеют КОСВЕНОЕ отношение друг к другу. И то, о чём я говорил НЕ зависит от уровней приоритетов, и даже самая "идеальная" диспетчеризация НЕ повлияет на это. А если время, за которое процессы завершат свою работу не имеет значения, то так-же не имеет смысла дальнейший диалог.
З.Ы. Пожалуйста, уважайте себя и других участников форума. Данная тема ниоткуда не высосана, и к онанизму отношения (пока:) не имеет.

Понимаете, SII, -и приоритетное планирование, и механизмы синхронизации - совершенно "полноправные" надстройки над системой разделения времени, которая, в случае с одним процессором (или числом процессоров меньшим числа потоков) не способна обеспечить "прозрачного" разделения, когда каждый поток имеет время отклика равное времени реакции его обработчика на внешние события (сглаживается приоритетом), и имеет возможность атомарности транзакции обмена данными (его никто не прервёт). И, поэтому, давайте попробуем разделить подход к в вопросу многопоточности, ведь так мы скорее придём к некоторому результату, нежели свалим всё в общую кучу и начнём копаться в хламе амбиций и различного рода неоправданых "имхо". Я выбрал подход со стороны синхронизации. Если Вам интересна тема диспетчеризации, то пожалуйта выкладывайте материал на обсуждение. Думаю, что у Вас достаточно опыта работы в этой области, и поэтому как у меня, так и у других интересующихся данным вопросом есть возможность узнать что-то новое.

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