Что такое торговля offs для “активного ожидания” по сравнению со “сном”?

Прежде всего, вы заблуждаетесь:

Блокирующие вызовы не являются «ожиданием занятости» или «спин-блокировками». Блокирующие вызовы переходят в спящий режим - это означает, что ЦП будет работать над другими задачами, ЦП не будет потрачен впустую.

По вашему вопросу о блокировании вызовов

Блокировать вызовы проще - их легко понять, проще разработать, проще для отладки.

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

Это компромисс - более быстрая разработка и ремонтопригодность? или масштабируемость.

I will try to be to the point as enough explanation is provided here through other answers and yes, learning from all these answers, i think a complete picture shall be. ---

Trade-off according to me shall between Responsiveness Vs Throughput of the system.

Responsiveness - can be considered from two perspectives

• over all system responsiveness, and
• a particular or per-process responsiveness

I think for responsiveness of the system, blocking calls are the best way to go. As it give the CPU to the other process in the ready queue, when the blocking-call in the blocked state.

And Of-course, for a particular process or per-process responsiveness, we shall consider a busy-wait/ spin-lock model.

Now, again to increase the overall system responsiveness we cannot decrease the time-slice (fine grain) for the scheduler, as this would waste too much of CPU resource in context switch. And thus throughput of the system would decrease drastically. Of-course, it is obvious that blocking model increases the throughput of the system, as the blocked calls does not consume CPU slices and gives it to the other/next process in the ready queue.

I think the best to go is-- design a system with a per-process responsiveness in mind, without effecting the overall responsiveness and throughput is-- through implementing a priority based scheduler, with considerations for priority inversion issues, if adding complexity does not bother you :).

Засыпание до тех пор, пока планировщик не разбудит вас, является нормальным / предпочтительным делом.

Вращение (альтернативный способ ожидания без сна) менее обычное дело и имеет следующие эффекты:

• Занимает процессор,

Это не одобряется, потому что это специфический для платформы хакер, который не имеет ничего общего с фактическим обучением программированию, но вместо этого позволяет обойти особенность IDE / OS - окно консоли, запускаемое из Visual Studio закрывается, когда программа завершает выполнение, и поэтому новый пользователь не может видеть вывод своей новой программы.

Bodging in System («пауза») запускает программу «паузы» в командной строке Windows и ждет, пока чтобы завершить работу, прежде чем она продолжит выполнение программы - окно консоли остается открытым, чтобы вы могли прочитать вывод.

Лучше было бы поставить точку останова в конце и отладить ее, но здесь снова возникают проблемы.

Важно отметить, что степень детализации нарезки потоков ЦП очень высока. Я бы высунул шею, чтобы также заметить, что все события, которые вы склонны блокировать, потребуют достаточно времени, чтобы возникнуть, компенсируя небольшой отрезок времени, в течение которого им приходилось ждать дополнительно, прежде чем разблокировать.

---

I Думаю J-16 указывает на то, что спящий (заблокированный) поток оставляет свой код и пространство данных неиспользованными в заблокированном состоянии. Это может привести к тому, что система откажется от ресурсов (например, кешей данных / кода), которые затем необходимо будет пополнить при освобождении блока. Следовательно, при определенных условиях блокировка может привести к увеличению потерь ресурсов.
компенсируя небольшой временной интервал, в течение которого им пришлось ждать дополнительно перед разблокировкой.

---

Я думаю, что J-16 указывает на то, что спящий (заблокированный) поток покидает свой код и пространство данных не используется в заблокированном состоянии. Это может привести к тому, что система откажется от ресурсов (например, кешей данных / кода), которые затем необходимо будет пополнить при освобождении блока. Следовательно, при определенных условиях блокировка может привести к увеличению потерь ресурсов.
компенсируя небольшой временной интервал, в течение которого им пришлось ждать дополнительно перед разблокировкой.

---

Я думаю, что J-16 указывает на то, что спящий (заблокированный) поток покидает свой код и пространство данных не используется в заблокированном состоянии. Это может привести к тому, что система откажется от ресурсов (например, кешей данных / кода), которые затем необходимо будет пополнить при освобождении блока. Следовательно, при определенных условиях блокировка может привести к увеличению потерь ресурсов.
Это также действительное примечание, и его следует проверять при разработке и реализации.
Но в большинстве случаев блокировка обычно лучше спин-блокировки.

// Адаптированный исходный код ASPI ...

    DWORD startStopUnit (HANDLE handle, BOOL bLoEj, BOOL bStart)
    {
       DWORD  dwStatus;
       HANDLE heventSRB;
       SRB_ExecSCSICmd s;





    //here
       heventSRB = CreateEvent (NULL, TRUE, FALSE, NULL);

       memset (&s, 0, sizeof (s));

       s.SRB_Cmd = SC_EXEC_SCSI_CMD;
       s.SRB_HaID = 0;
       s.SRB_Target = 0;
       s.SRB_Lun = 0;
       s.SRB_Flags = SRB_EVENT_NOTIFY;
       s.SRB_SenseLen = SENSE_LEN;
       s.SRB_CDBLen = 6;
       s.SRB_PostProc = (LPVOID) heventSRB;
       s.CDBByte[0] = 0x1B;
       s.CDBByte[4] |= bLoEj ? 0x02 : 0x00;
       s.CDBByte[4] |= bStart ? 0x01 : 0x00;

       ResetEvent (heventSRB);
       dwStatus = SPTISendASPI32Command (handle,(LPSRB) & s);
       if (dwStatus == SS_PENDING)
         {
//and here, don´t know a better way to wait for something to finish without processor cicles
        WaitForSingleObject (heventSRB, DEFWAITLEN);
         }
       CloseHandle (heventSRB);

       if (s.SRB_Status != SS_COMP)
         {
    printf("Erro\n");
        return SS_ERR;
         }

       printf("nao Erro\n");
       return s.SRB_Status;
    }