Wait for single object 2 ошибка

The cause to this error is the current Windows installation somehow being in a corrupted state. For some reason a simple file operation that should take less than a second is taking over half a minute and timing out, resulting in the error. As the first step, please use the Windows Update to ensure that your Windows is fully up-to-date. After installing all available Windows updates, verify all system files explicitly by running the following command in command prompt 

as Administrator

: sfc /scannow.

If the problem persists after updating Windows, we recommend running an anti-virus scan as it is possible that the system has been infected by a virus. You can use for example the free Malwarebytes anti-rootkit scan to check this.

Lastly, if the error still persists, you may need to use the Windows System Restore function to revert your computer to a previously working state. Unfortunately, after having investigated this extremely rare issue on few end-user PCs, we have not been able to identify the specific cause to what makes the system stall the failing operation for such long time period without no apparent reason.

В случае многопоточности иногда нам нужно дождаться завершения потока, прежде чем продолжить выполнение других действий.Для этого вы можете использовать функцию Windows API WaitForSingleObject или WaitForMultipleObjects. Обе эти функции ждут, пока объект не будет помечен как сигнализированный, прежде чем вернуться.
Итак, что это за сигнал? Прежде всего, мы можем предположить, что существует файл и два потока. Мы оговариваем, что этот файл может быть доступен и открыт только одним потоком одновременно. Как наш поток узнает, обращается ли этот файл в настоящее время к другим потокам? Мы можем позволить потоку ждать в бесконечном цикле. Один из циклов пытается открыть файл и получить к нему доступ, пока он не может быть открыт; хотя это может достичь цели, бесконечный цикл займет много памяти, поэтому окна устанавливают семафор. Простое понимание роли семафора — это бит флага. В нашей вышеупомянутой проблеме этот файл имеет семафор. Первоначально мы устанавливаем семафор в FALSE, и только когда семафор FALSE может открыть поток и получить доступ к файлу. Затем, когда приходит первый поток, семафор ЛОЖЬ, поток открывает файл для доступа и устанавливает семафор в ИСТИНА; когда первый поток обращается к файлу, приходит второй поток, а семафор еще не ИСТИНА, так что второй поток ждет.Этот процесс ожидания — WaitForSingleObject. WaitForSingleObject перейдет в очень эффективное состояние ожидания в спящем режиме во время процесса ожидания, который занимает очень небольшое количество процессорного времени.

WaitForSingleObject()

1. Форматировать

DWORD WaitForSingleObject( HANDLE hHandle, DWORDdwMilliseconds);

Есть два параметра, а именно THandle и Timeout (единицы миллисекунды).

Если вы хотите дождаться потока, вам необходимо указать дескриптор потока и соответствующее время ожидания. Конечно, если вы хотите ждать бесконечно, параметр Timeout может указывать системную константу INFINITE.

2. Цель

Он может ждать следующих типов объектов:

Event，Mutex，Semaphore，Process，Thread 

3. Тип возврата

Есть три типа возврата:

WAIT_OBJECT_0, что означает, что у ожидающего объекта есть сигнал (для потока это означает конец выполнения);

WAIT_TIMEOUT, что означает, что объект не получил сигнал в течение указанного периода времени (поток не был выполнен);

WAIT_ABANDONED указывает, что у объекта есть сигнал, но он по-прежнему не может быть выполнен, обычно из-за того, что блокировка не была получена или по другим причинам.

Пример кода выглядит следующим образом:

// ConsoleApplication1.cpp: определяет точку входа консольного приложения.
//

#include "stdafx.h"
#include "stdio.h"
#include "windows.h"
#include <iostream>
using namespace std;

int i = 0;
DWORD WINAPI FunProc(LPVOID lpParameter);

DWORD WINAPI FunProc(LPVOID lpParameter)
{
for (; i < 10; i++)
{
if (!(i % 10))
cout << endl;
else
cout << i << endl;
}
return 0;
}

void main()
{
cout << i << endl;
HANDLE hThread;
hThread = CreateThread(NULL, 0, FunProc, NULL, 0, NULL);
DWORD dwRet = WaitForSingleObject(hThread, 1);
if (dwRet == WAIT_OBJECT_0)
{
cout<< "Конец выполнения созданного потока" << endl;
}
if (dwRet == WAIT_TIMEOUT)
{
cout<< "Тайм-аут ожидания" << endl;
}
if (dwRet == WAIT_ABANDONED)
{
cout<< "Abandoned" << endl;
}
CloseHandle(hThread);
system("pause");
return 0;
}

Результат:

В этом коде сначала определите переменную i как 0 в начале, а затем выведите ее в функции main, чтобы в первой строке результата было 0.

После этого мы запускаем поток, вводим функцию потока FunProc и выводим остаток от i ++ до 10 в FunProc до тех пор, пока i> 10 не завершит цикл и поток не завершится. В это время результатом, возвращаемым в WaitForSingleObject, будет WAIT_OBJECT_0, что означает, что поток завершается нормально, и результатом является Вывод.

Среди них эффект WaitForSingleObject эквивалентен уровню, и программа может продолжить выполнение только после того, как результат будет возвращен в WaitForSingleObject.

Это время ожидания исчерпания семафора после завершения потока. Мы также можем установить второй параметр WaitForSingleObject наINFINITE, Можно ждать вечно. Результат:

Исходный текст ссылки:WaitForSingleObject

Другие ссылки:Функция и использование WaitForSingleObject

Плохая логика вообще. Например, есть следующие проблемы.

• CreateEvent/CloseHandle не должны выполняться при каждом событии ReadFile/WaitCommEvent.
• Использование GetCommMask/WaitCommEvent также неверно.
• Размер прочитанных данных, указанный в ReadFile, является фиксированным независимо от ситуации.
• Он также включает комментарий к @RbMm.

Вы можете изменить дизайн своей программы со ссылкой на следующие статьи и исходный код:

Синхронизация и перекрытие ввода и вывода

Последовательная связь

Бмо/мттти

Кроме того:
Я не заметил, что для WaitForSingleObject был указан дескриптор файла (а не дескриптор события), как указала @Rita Han.
Самая большая проблема в том.

Однако ситуация, что лучше сделать редизайн, не изменилась.
В источнике ответа @Rita Han нет описания WaitCommEvent и Overlapped для него. Кроме того, в ReadFile фиксируется размер прочитанных данных.

С другой стороны:
Хотя это не происходит в исходном коде вопроса, WaitCommEvent/WaitForSingleObject может генерировать событие, не указанное в SetCommMask.

• Пока WaitCommEvent ожидает завершения, измените маску события с помощью SetCommMask.
  Примечания — функция WaitCommEvent

  If a process attempts to change the device handle’s event mask by using the SetCommMask function while an overlapped WaitCommEvent operation is in progress, WaitCommEvent returns immediately. The variable pointed to by the lpEvtMask parameter is set to zero.

• Пока WaitCommEvent ожидает завершения, вызовите WaitCommEvent несколько раз, используя одну и ту же структуру Overlapped.
  Синхронизация и перекрытие ввода и вывода

  When performing multiple simultaneous overlapped operations on a single thread, the calling thread must specify an OVERLAPPED structure for each operation. Each OVERLAPPED structure must specify a handle to a different manual-reset event object.

  A thread should not reuse an event with the assumption that the event will be signaled only by that thread’s overlapped operation. An event is signaled on the same thread as the overlapped operation that is completing. Using the same event on multiple threads can lead to a race condition in which the event is signaled correctly for the thread whose operation completes first and prematurely for other threads using that event.

Документ описан выше, но в зависимости от драйвера/поставщика устройства, WaitCommEvent, который вызывается позже, заканчивается ошибкой, а WaitCommEvent, ожидающий завершения, — это lpEvtMask, возвращающий ноль (как в SetCommMask).

Для нескольких перекрывающихся структурных переменных:
Распространенным ноу-хау в программировании является то, что использование одной переменной для нескольких целей чревато ошибками.
Если вы проектируете в асинхронном и/или многопоточном режиме, лучше подготовить как минимум три структурные переменные Overlapped для ReadFile, WriteFile, WaitCommEvent.

О запуске ReadFile вне зависимости от состояния входного буфера:
Речь идет о вызове ReadFile с фиксированной длиной 256 байт без получения размера полученных данных во входном буфере драйвера устройства.

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

Например, цикл считывает по одному байту за раз, пока не произойдет ошибка тайм-аута, что означает конец полученных данных (тайм-аут чтения 1 байта не повлияет).
Или, как было сказано в предыдущей статье, используйте ClearCommError, чтобы получить размер данных, хранящихся во входном буфере драйвера устройства, и вызовите ReadFile, указав этот размер.

Не будет проблем с обработкой буфера на стороне приложения, которую вы объясняете.

О поведении WaiCommEvent при вызове SetCommMask:
Это может зависеть от используемого драйвера устройства.