c# - simbolos - visual studio archivo pdb

Lazy<T>: "La evaluación de la función requiere que se ejecuten todos los subprocesos"

Question

Tengo una clase estática con algunas propiedades estáticas. Los inicialicé todos en un constructor estático, pero luego me di cuenta de que es un desperdicio y que debería cargar cada propiedad cuando sea necesario. Así que cambié a usar el tipo System.Lazy<T> para hacer todo el trabajo sucio, y le dije que no usara ninguna de sus funciones de seguridad de subprocesos, ya que en mi caso la ejecución siempre fue de un solo subproceso.

Terminé con la siguiente clase:

public static class Queues
{
private static readonly Lazy<Queue> g_Parser = new Lazy<Queue>(() => new Queue(Config.ParserQueueName), false);
private static readonly Lazy<Queue> g_Distributor = new Lazy<Queue>(() => new Queue(Config.DistributorQueueName), false);
private static readonly Lazy<Queue> g_ConsumerAdapter = new Lazy<Queue>(() => new Queue(Config.ConsumerAdaptorQueueName), false);
public static Queue Parser { get { return g_Parser.Value; } }
public static Queue Distributor { get { return g_Distributor.Value; } }
public static Queue ConsumerAdapter { get { return g_ConsumerAdapter.Value; } }
}

Al depurar, noté un mensaje que nunca había visto:

La evaluación de la función requiere que se ejecuten todos los hilos.

Antes de usar Lazy<T> , los valores se mostraban directamente. Ahora, necesito hacer clic en el botón redondo con el ícono de hilos para evaluar el valor perezoso. Esto sucede solo en mis propiedades que están recuperando el .Value of Lazy<T> . Cuando se expande el nodo visualizador del depurador del objeto Lazy<T> real, la propiedad Value simplemente muestra un null , sin ningún mensaje.

¿Qué significa ese mensaje y por qué se muestra en mi caso?

Answer 1

Cree una variable local y asígnele el valor que desea inspeccionar.

Esto le permitirá inspeccionarlo porque el depurador no tiene que preocuparse por si el acceso a la propiedad perturbará su aplicación, ya que ya habrá accedido a ella al asignarla a la variable local.

Answer 2

He encontrado una página de MSDN titulada " Cómo actualizar valores de vigilancia " que lo explica:

Cuando evalúa una expresión en el depurador, uno de los dos iconos de actualización puede aparecer en la columna Valor. Un icono de actualización es un círculo que contiene dos flechas, que giran en direcciones opuestas. El otro es un círculo que contiene dos líneas onduladas que se asemejan a hilos.

...

Si aparecen los dos subprocesos, la expresión no se evaluó debido a una posible dependencia entre subprocesos. Una dependencia entre subprocesos significa que la evaluación del código requiere otros subprocesos en su aplicación para ejecutarse temporalmente. Cuando está en modo de interrupción, todos los subprocesos en su aplicación normalmente se detienen. Permitir que otros subprocesos se ejecuten temporalmente puede tener efectos inesperados en el estado de su programa y hace que el depurador ignore eventos como puntos de interrupción.

Todavía me gustaría una mejor explicación si alguien puede darla. Las preguntas que esto no responde incluyen: ¿Qué tipo de evaluación requiere que se ejecuten todos los subprocesos? ¿Cómo identifica el depurador este caso? ¿Qué sucede exactamente cuando haces clic en el icono de actualización de hilo?

EDITAR: Creo que me he topado con la respuesta al examinar Lazy<T> bajo ILSpy (por una razón completamente diferente). El captador de la propiedad Value tiene una llamada a Debugger.NotifyOfCrossThreadDependency() . MSDN tiene esto para decir:

[...] realizar una evaluación de función generalmente requiere congelar todos los subprocesos excepto el subproceso que está realizando la evaluación. Si la evaluación de la función requiere ejecución en más de un subproceso, como podría ocurrir en escenarios remotos, la evaluación se bloqueará. La notificación NotifyOfCrossThreadDependency informa al depurador de que debe liberar un hilo o abortar la evaluación de la función.

Básicamente, para evitar el caso molesto en el que intentas evaluar una expresión y Visual Studio solo se cuelga durante 30 segundos y luego te informa que "la evaluación de una función ha caducado", el código tiene la posibilidad de informar al depurador que debe descongelar otros hilos para que la evaluación tenga éxito o, de lo contrario, la evaluación se bloqueará para siempre.

Dado que ejecutar otros subprocesos puede interrumpir su sesión de depuración, como por lo general cuando evalúa una expresión, todos los demás subprocesos se mantienen congelados, el depurador no procesa y advierte automáticamente antes de permitirle saltar por el agujero de conejo.

Answer 3

Luché con esto durante horas y encontré el mensaje de error original sobre la necesidad de que todos los subprocesos funcionen de forma engañosa. Estaba accediendo a una base de datos existente desde una nueva solución y creando nuevas Entity Framework y capas de acceso a datos dentro de la nueva solución para acceder y asignar a la base de DB .

Hice dos cosas inicialmente mal. No definí correctamente la clave principal en mi entidad de C # POCO , y la table que estaba accediendo tenía un esquema único en la base de DB (no era dbo.tablename sino edi.tablename ).

En mi archivo DbContext.cs , hice lo siguiente para asignar la tabla bajo el esquema correcto. Una vez que corregí estas cosas, el error desapareció y funcionó bien.

protected override void OnModelCreating(DbModelBuilder dbModelBuilder)
{
base.OnModelCreating(dbModelBuilder);
dbModelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
dbModelBuilder.Entity<TableName>().ToTable("TableName", schemaName: "EDI");
}

Answer 4

Para mí, encontré que no importaba si tenía esto. this.Configuration.LazyLoadingEnabled = false; o = true; , si tuviera la línea en mi DBContext o no. Parece que ocurre, desde mi lectura sobre el problema, porque se está produciendo un subproceso y el depurador quiere permiso para ejecutarlo / le advierte antes de que lo estimule. Aparentemente, en algunos casos, incluso puede permitir que proceda de acuerdo con la respuesta de MUG4N aquí: .com/questions/29985150/…

Pero lo que encontré fue que podía solucionar el problema.

2 opciones:

1. Agregue .ToList() en sus Queues :

   var q = db.Queues.OrderBy(e => e.Distributor).ToList();

2. Encontré una solución al seleccionar Miembros No Públicos> _internalQuery> ObjectQuery> Vista de Resultados.

Answer 5

Supongo que el depurador está tratando de evitar influir en el estado de la aplicación al cargar las propiedades por usted.

Debe recordar que la carga lenta solo ocurre cuando hace referencia / accede a las propiedades.

Ahora, en general, no desea que la depuración afecte el estado de la aplicación, de lo contrario no dará una representación precisa de lo que debería ser el estado de la aplicación ( piense en las aplicaciones y depuración de subprocesos múltiples )

Echa un vistazo a Heisenbug