Prueba de Procesos Múltiples (Multithread)

Prueba de procesos múltiples

Alberto Rodriguez

Con VFP 6.0 Build 8167 los ejecutables que corren dentro de un mismo proceso (.DLL) no soportan ejecución simultanea de métodos.

Para entendernos, como se comentó en el artículo Procesos y Threads de esta revista en Abril de 1999: “Asumamos que el Metodo1 ejecuta una consulta que dura 15 secgundos y el Método2 ejecuta una consulta que dura 1 segundo. Si el Método1 se invoca antes de que se invoque el Método2 la llamada al método2 bloqueará durante 15 segundos la respuesta a la otra instancia.”

No obstante con VFP 6.0 Build 8492 (después de aplicar el SP.3) las cosas han cambiado.

Ahora se dispone de una nueva órden que es:

BUILD MTDLL FROM

que te permite construir un nuevo tipo de .DLL llamada de Subproceso Múltiple.

Para verlo visualmente nos podemos fijar en que la pantalla que controla los proyectos, al pulsar en el botón generar vemos:

Propiamente hablando el Build 8167 ya era Multithread pero como dos procesos coincidieran en el mismo método del mismo objeto uno de los dos tenía que esperar al otro.

Para hacer una prueba de su funcionamiento podemos hacer lo siguiente:

1.- Crea una clase tipo CUSTOM y especifícala como OLEPUBLIC y lláma DEMO al fichero contenedor de clases y a la clase llámala DemoTread.

2.- Crea un método que vamos a llamar ralentiza y escribe:

lparameters lnSegs

LOCAL x

lnSegs = IIF (EMPTY(lnSegs),0,lnSegs)

DECLARE Sleep In Win32api INTEGER
FOR x = 1 to lnSegs
	Sleep(1000)
ENDFOR

DECLARE INTEGER GetCurrentThreadId in 
Win32api

return GetCurrentThreadId()

Como sabes dentro de una DLL no podemos poner ‘situaciones de espera’ o interfaces: no se pueden usar formularios, messagebox, wait Windows o similar por eso utilizaremos una función del API de Windows que nos ralentiza nuestra consulta.

3.- Crea una página .ASP con el siguiente código:

lnSegs = Request("txtSegundos")

IF LEN(lnSegs) < 1 Then

lnSegs = "3"

END IF

lnSegs = CLng(lnSegs)

Set oServer = Server.CreateObject("proy1.demotread")

Response.Write("<B>Identificador del Thread</B>: " & oServer.ralentiza((lnSegs)) & "<br>")

Response.Write("<B>Hora actual</B>" &FormatDateTime(now,vbLongTime))

%>

<HR>

<form method="post"action="lento.asp">

Esperando durante <input type="text" name=txtSegundos size = "3" value ="<%=lnSegs %>">

segundos

<Input type="submit" value" Ejecutar de nuevo" name=button1>

</form>

4.- Asegúrate de que tu explorador permite la ejecución de Treahds simultaneos. Esto lo puedes ver si está marcada la opción de: (en el IE 5.0)

Herramientasa/Opciones de Internet/Opciones avanzadas

Opción de Examinar/Iniciar ventanas del explorador en un nuevo proceso.

5.- Carga el Explorer y ejecuta la página ASP varias veces hasta tener algo parecido a la imagen. Como puedes ver estamos usando Threads diferentes y la respuesta de unos llega antes que otros para los distintos tiempos que marcamos. Puede ser que en alguna ocasión un thread quede libre y el explorer te muestre el mismo ID pero si está ocupado te mostrará otro ID.

Ejecuta varios browsers lanzándolos de forma separada. No uses CTRL+N desde dentro de un Browser pues deben tener sesiones diferentes. Propiamente habría que utilizar Browsers diferentes.

Cambia los segundos de espera y observa el resultado. Si el Multithread esta funcionando verás que aunque hayas lanzado antes la opción de 15 segundos, el de tres segundos responderá antes de que llegue el resultado de la otra.

Esta posibilidad de liberar los bloqueos no sólo se aplica a las Páginas Activas sino también al Microsoft Transaction Server pues ahora puedes tener el mismo objeto instanciado varias veces y con consultas simultaneas.

Este Build resuelve un grave problema de escalabilidad que tenía VFP 6.0. El precio es:

1.- No puedes ya usar los viejos @GET, SAY, etc...

2.- Microsoft reconoce que el runtime del nuevo Build puede ser ligeramente más lento que el anterior pero con las nuevas máquinas que hay casi ni se nota.