¿Por qué se prefiere InvokeRequired sobre WindowsFormsSynchronizationContext?

En cualquier momento el principiante pregunta algo como: ¿Cómo actualizar la GUI desde otro hilo en C #?, la respuesta es bastante directa:

if (foo.InvokeRequired)
{
    foo.BeginInvoke(...)
} else {
    ...
}

¿Pero es realmente bueno usarlo? Justo después de que el hilo no GUI ejecutafoo.InvokeRequired el estado defoo puede cambiar. Por ejemplo, si cerramos el formulario justo después defoo.InvokeRequired, pero antesfoo.BeginInvoke, llamando afoo.BeginInvoke dará lugar aInvalidOperationException: Invoke o BeginInvoke no se pueden invocar en un control hasta que se haya creado el identificador de ventana. Esto no sucedería si cerramos el formulario antes de llamar aInvokeRequired, porque seríafalse incluso cuando se llama desde un hilo no GUI.

Otro ejemplo: digamosfoo es unTextBox. Si cierra el formulario y luego se ejecuta ese subproceso no GUIfoo.InvokeRequired (que es falso, porque el formulario está cerrado) yfoo.AppendText conducirá aObjectDisposedException.

Por el contrario, en mi opinión usandoWindowsFormsSynchronizationContext es mucho más fácil: publicar devolución de llamada usandoPost ocurrirá solo si el hilo todavía existe, y llamadas síncronas usandoSend lanzaInvalidAsynchronousStateException si el hilo ya no existe.

No está usandoWindowsFormsSynchronizationContext simplemente más fácil? ¿Me estoy perdiendo de algo? ¿Por qué debería usar el patrón InvokeRequired-BeginInvoke si no es realmente seguro para subprocesos? ¿Qué piensas que es mejor

Respuestas a la pregunta(2)

Su respuesta a la pregunta