متى يمكن أن يعود ManualResetevent.set () كاذبة؟

Question

وفقًا لوثائق MSDN ، فإن Set () و Reset () على ManualResetEvent (أو أي eventwaithandle) يعيد مؤشر منطقي ما إذا كانت العملية ناجحة أم لا.

تحت أي ظرف من الظروف ، يمكن أن يعود هذا الاتصال كاذب ، وماذا من المفترض أن أفعل إذا حدث ذلك؟

Answer 1

لم أكن متأكدًا من كيفية الإجابة على هذا والنظر في الكثير من أمثلة MSDN ، يتم تجاهل قيمة الإرجاع المحددة ، لذلك يجب ألا تكون مهمة أو من المحتمل أن تحدث.

لكن هذا لم يكن جيدًا بما فيه الكفاية. قمت بإطلاق VM الخاص بي وفتحت عاكس لإلقاء نظرة على الكود. لم يتم تعيين ManualResetEvent ولكنه يرث من EventWaithandle الذي يفعل. هذا هو الرمز:

public bool Set()
{
    bool flag = Win32Native.SetEvent(base.safeWaitHandle);
    if (!flag)
    {
        __Error.WinIOError();
    }
    return flag;
}

حيث يتم استيراد setevent من kernel32:

[DllImport("kernel32.dll", SetLastError=true)]
internal static extern bool SetEvent(SafeWaitHandle handle);

استدعاء WinioError () فقط يستدعي getLastwin32Rorr الذي لا نهتم به حقًا. هذا يعني في الأساس أن تعود المكالمة إلى خطأ ، كان من الممكن أن يحدث خطأ إلى حد ما في الكود الأصلي Win32.

تتجاهل وضع هذه المعلومات مع حقيقة أن الكود المستضاف في وثائق MSDN الرسمية يتجاهل قيمة الإرجاع (لماذا لا؟ ما الذي ستفعله إذا فشل kernel على أي حال؟) يمكنك تجاهلها بأمان إذا كنت تريد تنظيف منطقك بت أو احصل عليها وتسجيلها إذا كنت متحذرا بشكل خاص.

Answer 2

لست متأكدًا من أن خطأ السجل ومتابعة التنفيذ سيكون كافيًا. نتيجة خاطئة من set () يمكن أن تجلب سلوكًا خاطئًا في تزامن المواضيع التي تتم إدارتها بواسطة معالجات الانتظار. هذا هو Multithreading ... رؤيتي للتعامل مع مجموعة False Set () - رمي الاستثناء ، والتي ربما في معظم الحالات يمكن أن تكون غير محدودة.