c# - varias - .NET Web Service & BackgroundWorker hilos

que es backgroundworker c#

Question

Estoy tratando de hacer algunas cosas de sincronización en un método de servicio web. Supongamos que tengo la siguiente llamada a la API: http://www.example.com/api.asmx

y el método se llama GetProducts () .

En estos métodos de GetProducts, hago algunas cosas (por ejemplo, obtengo datos de la base de datos) justo antes de devolver el resultado, quiero hacer algunas cosas de sincronización (por ejemplo, enviarme un correo electrónico).

Entonces esto es lo que hice.

[WebMethod(Description = "Bal blah blah.")]
public IList<Product> GetProducts()
{
// Blah blah blah ..
// Get data from DB .. hi DB!
// var myData = .......
// Moar clbuttic blahs :) (yes, google for clbuttic if you don''t know what that is)
// Ok .. now send me an email for no particular reason, but to prove that async stuff works.
var myObject = new MyObject();
myObject.SendDataAsync();
// Ok, now return the result.
return myData;
}
}
public class TrackingCode
{
public void SendDataAsync()
{
var backgroundWorker = new BackgroundWorker();
backgroundWorker.DoWork += BackgroundWorker_DoWork;
backgroundWorker.RunWorkerAsync();
//System.Threading.Thread.Sleep(1000 * 20);
}
private void BackgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
SendEmail();
}
}

Ahora, cuando ejecuto este código, el correo electrónico nunca se envía. Si elimino el comentario de Thread.Sleep ..., se envía el correo electrónico.

Entonces ... ¿por qué se derriba el hilo del trabajador de fondo? ¿depende del hilo principal? ¿Es esta la manera incorrecta en que debería estar haciendo un hilado de fondo o con bifurcación, en aplicaciones web asp.net?

Answer 1

Puede ser derribado porque después de 20 segundos, esa instancia de BackgroundWorker puede ser basura recolectada porque no tiene referencias (salió del alcance).

Answer 2

Re productor / consumidor; básicamente, vale la pena mantener algún tipo de acelerador. En el nivel más simple, se podría usar un Semaphore (junto con el ThreadPool normal) para limitar las cosas a una cantidad conocida de trabajo (para evitar saturar el grupo de subprocesos); pero una cola productor / consumidor probablemente sería más eficiente y administrada.

Jon Skeet tiene una cola así ( CustomThreadPool ). Probablemente podría escribir algunas notas sobre eso si quisiera.

Dicho esto: si llama a un sitio web externo, es muy probable que tenga muchas esperas en los puertos IO / finalización de la red; como tal, puede tener un número ligeramente mayor de subprocesos ... obviamente (por el contrario) si el trabajo estaba vinculado a la CPU, no tiene sentido tener más hilos que núcleos de CPU.

Answer 3

BackgroundWorker es útil cuando necesita sincronizar de nuevo (por ejemplo) una hebra UI *, por ejemplo, por afinidad. En este caso, parecería que simplemente usar ThreadPool sería más que adecuado (y mucho más simple). Si tiene grandes volúmenes, entonces una cola de productor / consumidor puede permitir una mejor regulación (para que no se ahogue en los hilos), pero sospecho que ThreadPool estará bien aquí ...

public void SendDataAsync()
{
ThreadPool.QueueUserWorkItem(delegate
{
SendEmail();
});
}

Además, ¿no estoy seguro de lo que quieres lograr durmiendo? Esto simplemente atará un hilo (sin usar CPU, pero tampoco sirve). ¿Cuidado para elaborar? Parece que estás pausando tu página web actual (es decir, el Suspenso ocurre en el hilo de la página web, no en el hilo del correo electrónico). ¿Qué está tratando de hacer aquí?

* = en realidad, usará el contexto de sincronización que esté en su lugar