Seleccionar una biblioteca de tiempo de ejecución

Es posible que necesite una aplicación, del tipo de las aplicaciones para servidores de Internet, por ejemplo, FoxIsapi, donde desea crear una instancia de un formulario para utilizarlo en la asignación al HTML equivalente. La utilización del nuevo tiempo de ejecución vfp7t.dll elimina algunas características no críticas, lo que mejora el rendimiento general de las aplicaciones de servidor de varios subprocesos.

Un error habitual a la hora de elegir un servidor es creer que una aplicación se escalará automáticamente simplemente generando la .dll para que utilice el nuevo tiempo de ejecución. A veces se puede hacer, pero también debe tener en cuenta los problemas que implica la utilización de llamadas a la API de Visual FoxPro, escalabilidad, reentrada y contención de recursos.

Utilizar llamadas a la API de Visual FoxPro

Si utiliza bibliotecas FLL de Visual FoxPro o bibliotecas estándar DLL de Windows que realizan llamadas a la API de Visual FoxPro, debe tener en cuenta determinadas cuestiones al diseñar los servidores. La API de Visual FoxPro no determina inmediatamente a qué proyecto (.dll) pertenece una llamada determinada. Por lo tanto, existe la posibilidad, aunque remota, de que se realice una llamada a la API con relación a un proyecto (.dll: almacén local de subprocesos). Esto puede ocurrir si la biblioteca FLL/DLL crea una instancia de un servidor .dll de Visual FoxPro diferente antes de realizar su llamada a la API. Si su servidor tiene este problema, existen varias soluciones posibles:

• Cree una copia diferente del archivo de la biblioteca de tiempo de ejecución vfp7t.dll y sitúela en la misma carpeta que el servidor .dll. El servidor siempre busca primero en la carpeta del servidor antes de intentar encontrar los archivos en la carpeta System de Windows o en la carpeta donde se procesa el cliente. Al tener su propia biblioteca de tiempo de ejecución, el servidor no tendrá conflictos con otros servidores .dll, siempre que éstos no estén en la misma carpeta. Como este comportamiento (copiar o cambiar el nombre del tiempo de ejecución automáticamente) es predeterminado del tiempo de ejecución Vfp7r.dll, los problemas de la API antes descritos sólo se manifiestan en el tiempo de ejecución Vfp7t.dll.
• Limite su aplicación a un solo servidor .dll. Si utiliza varios servidores .dll (proyectos), existe la posibilidad de que haya conflictos de la API. Recuerde que un proyecto puede contener muchas clases OLEPUBLIC, de manera que no es necesario tener un proyecto diferente para cada OLEPUBLIC. Tenga en cuenta que, en los equipos compartidos, es posible que alguna persona instale otros servidores COM de Visual FoxPro que podrían causar conflictos con el suyo si se ejecutan simultáneamente.

Problemas de escalabilidad

El tiempo de ejecución de varios subprocesos de Visual FoxPro permite servidores en proceso de Visual FoxPro muy escalables. Aunque el tiempo de ejecución administrará automáticamente la escalabilidad de los servidores, puede suceder que algunos bucles de código estrechos no permitan que la conmutación entre subprocesos se realice con tanta frecuencia. Un ejemplo sería un bucle DO WHILE muy estrecho. Si tiene problemas de escalabilidad, puede incluir un código como el del siguiente ejemplo, que obliga al procesador a conmutar los subprocesos:

DECLARE Sleep IN Win32API INTEGER   
SLEEP(0)

Aunque puede utilizar subprocesamiento múltiple en un equipo con un solo procesador, tenga en cuenta que no obtendrá los resultados que espera. Por ejemplo, en un equipo con un solo procesador, el subprocesamiento múltiple sólo produce una mejora del rendimiento cuando se combinan tareas largas y cortas. Las llamadas a métodos de múltiples subprocesos, como se describe en este ejemplo, pueden parecer más lentas.

En el ejemplo, se llama al mismo tiempo a los métodos A y B. En un componente de un solo subproceso, las peticiones se serializan, de manera que B no comienza hasta que termine A. Con el subprocesamiento múltiple, los dos subprocesos activos reclaman la atención del procesador.

No sólo aumenta el promedio de tiempo que necesitan para completarse; también el procesador utiliza más tiempo para conmutar de un subproceso a otro.

El problema es que los métodos A y B tardan el mismo tiempo.

Por ejemplo, si el método B requiere sólo tres partes de tiempo para completarse, el usuario del sistema percibirá una mejora importante en la respuesta del método B, y sólo una pequeña degradación en el tiempo necesario para ejecutar el método A.

El subprocesamiento múltiple muestra más ventajas en aquellos casos donde la mayoría de los subprocesos pasan una parte importante del tiempo bloqueados, por ejemplo, esperando la E/S de un archivo, para que se pueda ejecutar el código de otros subprocesos en un momento determinado.

Si está pensando en utilizar una aplicación en un equipo con un solo procesador que tenga características que proporcione un mínimo bloqueo de los subprocesos, es posible que desee utilizar el tiempo de ejecución vfp7r.dll. En equipos con varios procesadores y en la mayoría de las demás aplicaciones, debe considerar la posibilidad de utilizar vfp7t.dll para servidores .dll.

Reentrada

En el modelo Apartamento, la reentrada hace referencia a la siguiente secuencia de eventos:

1. El subproceso de ejecución de un apartamento entra en el código de un objeto porque se ha invocado una propiedad o método.
2. Mientras el subproceso está en la propiedad o método, otro subproceso invoca una propiedad o método del objeto, y la automatización serializa esta petición; es decir, sitúa la petición en la cola de espera hasta que el subproceso que posee el apartamento del objeto termina el miembro que está ejecutando en ese momento.
3. Antes de que el subproceso llegue al final del miembro, ejecuta el código que proporciona el control del procesador.
4. La automatización indica al subproceso que comience a ejecutar la petición serializada, de modo que el subproceso vuelve a entrar en el código del objeto.

La nueva petición puede ser para el miembro que el subproceso ya está ejecutando, en cuyo caso el subproceso entra en el miembro por segunda vez, o puede ser para otro miembro. Si el segundo miembro no cede el control, terminará el procesamiento antes que el primer miembro. Si modifica los datos del módulo que estaba utilizando el primer miembro, puede obtener resultados imprevistos.

Mediante la serialización de las llamadas a métodos y propiedades de cada apartamento, la automatización impide la reentrada, a menos que el código proporcione el control del procesador. El código puede proporcionar el control del procesador mediante alguna de las acciones siguientes:

• Llamar a DoEvents.
• Invocar a las propiedades o métodos de un objeto en otro subproceso o en otro proceso. Si se establece la propiedad Application.AutoYield como False (.F.) se suspenderá el procesamiento de los eventos intermitentes entre las líneas del código que se está ejecutando.
• Invocar un método entre procesos o entre subprocesos desde un método.

No debe incluir código que proporcione el control del procesador a menos que escriba con cuidado todo el código de un objeto para que no importe que dos miembros se ejecuten al mismo tiempo.

Contención de recursos

La nueva biblioteca de tiempo de ejecución vfp7t.dll evita que los objetos tengan acceso a los datos de aplicación de otros objetos, incluidos datos globales del entorno declarados e intrínsecos. Algunos recursos pueden presentar problemas de contención, entre ellos:

• Archivos
• Registro
• Data

La E/S de archivo presenta contenciones de recursos que se pueden tratar fácilmente mediante código, ya que la administración de archivos se realiza mediante el sistema operativo. Cuando se utiliza un archivo, un servidor puede abrir (y bloquear) un archivo para que otros objetos vean que está en uso. En este caso, un servidor escrito correctamente esperará a que el archivo esté disponible o bien tratará el error sin problemas. Los archivos también se pueden abrir compartidos, en cuyo caso el servidor debe saber que otros objetos podrían modificar los valores.

Un caso habitual es el de los archivos INI donde varios objetos diferentes pueden leer o escribir valores. El proceso de lectura y posterior escritura de un valor en un archivo INI consta de dos pasos. Por lo tanto, existe la posibilidad de que el valor que lea un cliente no sea necesariamente el mismo que sobrescribirá más tarde porque otro cliente lo modificó primero; en este caso, sería necesario resolver el conflicto.

Igual que los archivo INI, el Registro almacena valores a los que pueden tener acceso varios clientes. Las aplicaciones deben utilizar las rutinas comunes de la API de Windows para tener acceso al Registro; por ejemplo, Foundation Classes de FoxPro en REGISTRY.VCX. De nuevo, el diseño del servidor debe tener en cuenta que existe la posibilidad de que los valores de las claves del Registro cambien desde que se lee hasta que se escribe. Las rutinas de la API de Windows evitan la necesidad de resolver conflictos.

Los datos son un recurso complejo de tratar. Afortunadamente, el lenguaje de Visual FoxPro disponible en los tiempos de ejecución proporciona toda la información y funciones necesarias para tratar los problemas de contención de recursos. Para obtener más información acerca de cómo tratar los datos compartidos, vea Programar para acceso compartido.

Vea también

Controlar el bloqueo de llamadas | Lenguajes admitidos en tiempos de ejecución | Interoperabilidad e Internet | Notas sobre la programación de servidores de automatización | FoxIsapi